royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: [Discussion] Package change names (was Re: 0.9.3 Release)
Date Tue, 05 Jun 2018 11:35:32 GMT
Hi Alex,

2018-06-04 20:15 GMT+02:00 Alex Harui <>:

> Hi Carlos,
> At this point, I think I've addressed all of the compiler issues that
> result in unnecessary output or processing.  If Harbs is finished with the
> framework changes, then I think we can try building Jewel with and without
> Basic and see if there are still issues.

I'll give it a try and see. But If we get things working ok, I still expect
we can move things from what we call currently Basic to it's own SWC (TLCs,
CSS and direct related beads)
I still have to make a small list example like Harbs requested me for this.

> I have to say that my understanding of your responses seem counter to how
> the main patterns in Royale's composition-based frameworks are supposed to
> work.  Here are some of the disconnects as I see them.

I think we really have the same goals in mind and there's only one point
that I'm not like (make Jewel extend a library with Basic TLCs, direct
beads and CSS).

> 1. Jewel Views, Models, Controllers and other beads should not be tied to
> Jewel TLCs.  TLCs are intended to be example compositions of beads.  See
> the "Exploded Component" section of "Terminology and Concepts".

Right, I still need to get to this point and check this along with SWF
version. This days I was concentrating in get IE11 work. Right now is
almost done, and only need to solve 2 problems (Slider and SVG colors) to
get that part complete.

> 2. Jewel Views should not be tied to Jewel Models.   Jewel may not even
> need its own Models for many controls.  The default TextButton model just
> has text and html properties.  There shouldn't be anything
> component-set-specific about such a model.

Right. You said that because you saw some incorrect relationship in the
actual code? if so we need to fix that.

> 3. Folks are encouraged to create compositions from beads at all levels of
> the framework, from all component sets, in order to maximize code reuse.
> So, if you want to split Basic beads into a separate SWC from Basic TLCs,
> you must also agree to split Jewel beads into a separate SWC away from
> Jewel TLCs.

Yes, I don't want beads in Jewel of general purpose. If I find someone I'll
move to the shared lib. This days I removed some that was copied temporal
(i.e MultilineLabel), and modified other beads that was just copied until
now (layout beads, now has a different code with CSS handling, and still
need more work). But I have still more code that should be moved as we
finishing this discussion or even removed.

>    That way, folks who compose Jewel beads into another component set will
> enjoy the same benefits you are claiming will happen if we split Basic
> beads from Basic TLCs.


> 4. Because there are different levels of complexity, it does not make
> sense to try to make one universal library of re-usable pieces.  Also,
> because we want third-parties to have a viable ecosystem for their
> components, we want to make sure that composition works well in a
> decentralized organizational model.


> 5. Everything in Royale, even the TLCs need to be reusable.  The MXML
> Component model requires it, especially of TLCs.
> I noticed just now that Jewel does not yet have any "composite" components
> (meaning, components composed of other components).  You may want to work
> on Jewel DataGrid, for example, and have it use the Express type-agnostic
> DataGridModel.  It might help illustrate how different levels of bead
> complexity should work.

Maybe Jewel List is the only composite component in Jewel right now right?

I need to finish some few things and then will handle this ok?


> My 2 cents,
> -Alex
> ´╗┐On 6/1/18, 1:26 AM, " on behalf of Carlos Rovira"
> < on behalf of> wrote:
>     Hi Alex,
>     2018-06-01 8:08 GMT+02:00 Alex Harui <>:
>     >
>     >
>     >     Key word here is *optional* not *mandatory*. Take this in mind,
> since
>     > while
>     >     I have the option to use it or not, I even should have the
> option to
>     > link
>     >     it or not, since there's no obligation or requeriment to use.
>     >
>     > Everything is currently optional the way we have it, but the
> principle of
>     > code re-use is primary.
>     I think here can't agree. Until the refactor, I couldn't get rid off
> all
>     the Basic things I didn't want. Rigth now is truly optional. In all
>     possible views (code, css and library linking), while still you can
> take
>     the old route as well. Everybody wins here.
>     > Copying code to avoid a project dependency is not a recommended
> practice.
>     >
>     If I copy code is to change it. In the final picture you should never
> see
>     the same code. For example yesterday I notice the existence of
> UIDUtils,
>     that was almost the same code than RPCUIutils, so I removed the later.
> This
>     days I plan to work on jewel layouts. This code is already different,
> but
>     it will be even more, more CSS based and with more features. But it
> started
>     as a copy of similar layout code in Basic. I think that's a normal
> process.
>     >
>     > The Emulation set will use Basic beads for models and controllers
> and lots
>     > of other things, if the simple implementations suffice.
>     >
>     I think this will be difficult or at least I don't see how that will
> work.
>     If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
>     Button, not Basic Button, and the Jewel Theme. In general, Jewel
> controls
>     and components setup a concrete visual structure through
> "createElementwith
>     a concrete style structure that MXRoyale will need to replicate in
> code. So
>     Basic seems very far from this requirement. for complex components
> where
>     views are in place is more natural to use Jewel parts than go Basic.
> For
>     example Slider in Basic has a different approach than in Jewel, so
> trying
>     to make the visuals in Jewel work with Basic won't work.
>     I think to make this happen we should think not in actual Basic or
> Jewel
>     but in only one unified set that can rely less in createElement and
> more in
>     view implementations so we can have separated SWCs with Basic and Jewel
>     views.
>     > I mentioned this before.  The DataGridModel in Express is
> type-agnostic
>     > (dataProvider is Object) whereas in Basic is assumes the
> dataProvider is an
>     > Array.  And you can configure the Basic one to use different
> dataProviders
>     > of different types.  That's on purpose, for PAYG (no extra code to
> handle
>     > different types) and to help folks ensure type-safety.  But our
> users want
>     > less configuration so you can pass "anything" into Express DataGrid's
>     > dataProvider, just like Flex.
>     >
>     In Jewel, List has the problem that ICollectionView was not
> sufficient, so
>     it has an extension of that class to use ArrayList that seems to be the
>     normal use case.
>     But people can override that bead for general use or in a particular
> case.
>     >     Doubling no, jut one: Foundation - Basic. The rest is up to
>     > discussion, but
>     >     since are not required right now (are already not linked or
> mandatory)
>     > like
>     >     MDL, CreateJS, and more, I'm fine with it. I recommend in the
> future
>     >     refactor as well, but that should be made by volunteers if they
> want
>     >
>     > I think that's inconsistent.  If you agree above that some other
> component
>     > set can re-use Jewel Views, then you will need to break Jewel beads
> out
>     > into a separate SWC as well according to your arguments.  And that
> will
>     > double the number of SWCs.  Instead, I think we have ways to use the
>     > current organization to address your concerns about extra CSS
> processing.
>     >
>     >
>     I think there's a misunderstanding here. Let's see If I can explain
> what I
>     really want to mean: Right now Basic has all code needed to build a UI
> Set
>     plus, the concrete implementation of that UI Set plus a CSS that wires
> all
>     of it in a concrete waty. I think that's not right. If you extract all
>     reusable code to Foundation library, you'll get with a library (Basic)
> with
>     just TLCs and CSS, and that library will have exact same pieces than
>     (Jewel), TLCs of that concrete implementation that are not reusable at
> all,
>     and CSS that wires a concrete setup of beads (in Core, Foundation and
> the
>     particular UI Set). As we said MDL or CreateJS are not our main
> target, so
>     other volunteers should take that into account if they want or leave
> it as
>     is, since the new setup supports it, while the old one is more
> restrictive
>     and we have no option to setup one wat or the other.
>     >     But links all existing available libraries? when you program in
> C++ you
>     >     link what you need. So in Royale there's no point to link a
> Basic UI
>     > Set
>     >     (TLCs and CSS) if I'm going to not use it, but use another one.
>     >
>     > The user is in complete control over the number of SWCs that get
> read in,
>     > even for Ant, IDEs and command-line users.
>     That's not true in the old setup. The compiler process *reads* all CSS
> and
>     if we have not bugs nothing will end there. And more important, I was
> not
>     able to remove that depency since it was mandatory. Nowadays the actual
>     setup let you choose.
>     >   The compiler only reads in the SWCs it is told to read in.
>     Today that's is real, I can remove Basic, and the compiler will not
>     complain. But that not was true until now.
>     > The default royale-config.xml currently uses a wildcard.  Will it
> always?
>     > Maybe not if we someday have enough SWCs that reading them all in
> becomes a
>     > problem.   If you specify the exact set of SWCs that you would in a
> Maven
>     > pom, you will enjoy the same benefits of the compiler only reading
> those
>     > SWCs, if any.
>     Right. That's exactly what I want, be able to specify the library
> pieces I
>     want to use and have the choice to link as needed, so as a developer be
>     conscious of what code I have available. Maybe other basic users will
> want
>     to link all and don't worry about it, but we need to support experts as
>     well and give them possibility to fine grained configuration.
>     Another point: when I did the refactor I reported lots of hidden
> problems
>     that arise. There was libraries bringing Basic, and Basic wasn't
>     configured, the separation brought us more clarity and shows problems
> that
>     nobody was aware.
>     > It is simply a trade-off of configuration effort vs compile-time.
> Also
>     > having more SWCs get loaded should mean more options offered in
>     > code-hinting which is, IMO a good thing for now, but probably not in
> the
>     > future.  So, don't be worried about how many SWCs get read in.
> Users can
>     > control that.
>     >
>     *now* can control that. And more over, I prefer two libraries that one
> big
>     one (if not as I said we will have one single library and will compile
> all
>     framework code each time we make a change right?, so even for us,
> framework
>     developers, not only improves organization and separation, but improve
>     compile times in libraries, that seems other point to pursue.
>     >
>     > I am going to try to move the exclude-defaults-css to the loading
> phase
>     > instead of the output phase.  I think once I finish that and Harbs
> finishes
>     > removing class selectors we can see if there are any remaining
> issues or
>     > concerns with the current set of libraries.
>     >
>     I think that can be a good improvement. Seems more natural and seems as
>     well to that probably the rest of the process will be faster.
>     But do don't be deceived, one thing are bugs or improvements and other
>     different is structure and organization. Even if we get the
>     bugs/improvements working, that will not change the fact that is wrong
> to
>     link a library that will not be use. If you are saying is optional,
> let's
>     be consistent and make it truly optional. If not seems to me more like
> a
>     political promise.
>     Thanks
>     --
>     Carlos Rovira
> 7C1844120f173641f668f408d5c7995520%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636634383741019830&sdata=fwtYo76SgK6192czpWyQzdMv%
> 2B8Y3fcSZd62j1iu%2B8qs%3D&reserved=0

Carlos Rovira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message