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 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.
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".
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.
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.
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.
My 2 cents,
-Alex
On 6/1/18, 1:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi Alex,
2018-06-01 8:08 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
>
>
> 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
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1844120f173641f668f408d5c7995520%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634383741019830&sdata=fwtYo76SgK6192czpWyQzdMv%2B8Y3fcSZd62j1iu%2B8qs%3D&reserved=0
