FWIW, I think there is still a disconnect here. After looking at Carlos's
diagram with a Foundation layer, maybe the confusion is around how to think
about Composition-based instead of Inheritance-based components. There should
be no desire to make every component set use only things from a single
"foundation" layer. That's why I wanted to close on the discussion about using
Express beads in Jewel. So maybe we should put this thread on pause and finish
up that discussion.
Couple of other thoughts:
-There should be beads of varying complexity, from small, simple (Basic), to
more powerful or type-agnostic (Express). This latter category of beads don't
belong in a "foundation" layer as they are a layer above the Basic ones. Yet
Component Sets are welcome and even encouraged to leverage these more complex
beads. Our users have asked for that.
- As Harbs is saying, and I said earlier, Core is intended to be
implementation-agnostic and identify the parts/roles in the framework. Basic
beads, especially the Container beads, are a specific implementation, knowing
that SWF and JS are the outputs. Who knows what will be required in the
implementation of component sets for other outputs.
My 2 cents,
-Alex
On 5/29/18, 11:02 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi
2018-05-29 17:44 GMT+02:00 Harbs <harbs.li...@gmail.com>:.
>
>
> OK. I define Core a bit differently. Core defines the *architecture* or
> “scaffolding” of a Royale application. I don’t believe a Royale
application
> can be compiled from Core alone.
>
> Core is assumed to be a prerequisite for almost all other Royale libs
> (except Testing and Language). It should not have dependencies on other
> libraries or particular implementation details.
>
>
Right, I was not taking into account Language and Testing since for me is
even more "platform" or event more "atomic", but in essence we are talking
the same here.
>> 4. What are the advantages and disadvantages of making Basic a dependency
> >> for other component sets?
> >>
> >
> > I think this is mostly explained here, and a image use to be better than
> > thousand words, but the image mix graphs and explanations:
> >
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%2FDbH4iG.jpg&data=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691163168&sdata=A1StIlX4vcrkQ%2F8EF7o8SPoGD28pmyHp6amM%2BzYQqNI%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%2FDbH4iG.jpg&data=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691173177&sdata=IKoHqY9iflgHix7NbSbw1mO9wptThnLbFv7tLFIE4DU%3D&reserved=0>
>
> Here is what the dependencies are currently:
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2F8n3dxgv45qus3jp%2Froyale.png%3Fdl%3D0&data=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691173177&sdata=Umo%2F2xF%2FrfGZNybFfc%2FwbtkOr8UnRvVwKhlF6wblr9o%3D&reserved=0
>
>
good to see how you see it.
> I don’t understand the point of changing the dependencies around.
>
> To me the advantages of making Basic a dependency is:
>
> 1. A clearer (to me), flatter dependency tree.
>
your's a mine seems to be equally flatter for me.
> 2. A “base” component set to use (or partially use) for composition.
>
Take into account that Jewel does not subclass any component in Basic. MDL
should not do it, since extend a control from basic really does not bring
it nothing. I did in that way since at that time I was young in creating UI
sets, but I never was completely happy of that way. But, again, both models
make possible to extend a set and create a new one from that point, but
yours make that mandatory, so for me less flexible.
> 3. A logical place to put shared beads.
>
This is resolved with "Foundation" library. Finaly we'll be doing the same,
using a common library that reuse beads.
>
> What is gained by removing that dependency?
>
Well, while both versions brings the same benefits, as I tried to respond
in the responses to that 3 points, I think separate beads and coming code
in Foundation makes Royale more flexible. I talk about this several times,
and I think advantages are clearly shown in the schema image, but I'll try
to summarize it again:
What improvements we get? (I'm supposing we have Foundation library with
beads and common code previously in Basic, and some now in Core, and think
that Basic ui set for me is only the controls and components and the css,
not the beads and code that will be in Foundation)
1.- Without Basic, or any mandatory UI sets, we remove the processing of
the CSS beads file that is part of every UI set. This is critical, since
far beyond compiler bugs, we don't want our app to process a file that wire
a lots of beads, since the right bead file to process is only the UI Set
the user wants to use.
1.a-If you want to use Jewel, but declare first Jewel and then Basic,
Basic setup wins over Jewel, and this shows clearly that this is nothing
good.
1.b- This introduces, unwanted content, increase size, and is a hole of
possible problems that we are creating for free. This one solely is huge
one.
2.- We as well remove the processing of CSS html rules, that are equally a
generator of free problems.
3.- Something that comes clearly as you think more in it... why make Jewel
dependent of Basic if Jewel don't extend any Basic component?
3.a- If we continue thinking in that, why we are separating in libraries
if we finaly link all? If we link all, then we should join Core, Basic,
Jewel, Binding, Network, and so on...
4.- Separation is good since this make framework developers try to use the
logical pieces they have. In the current way, we'll tend to mess things
since we have lots of pieces available and can take the easy way.
5.- The new dependencies is more flexible: we can use Jewel, and at a time,
use Basic if we want, is up to the user to choose it, and that's more
powerful that make them link a Basic UI Set that maybe he doesn't want use
never
6.- Why make an UI Set principal over the others? what have Basic over
Jewel, or the opposite? Those are the same, but we have more than one since
are designed with different goals in mind, so there's no point on make one
link another (and again more over when the new one doesn't use any single
class from the parent). That's for me clearly useless.
7.- Future major versions: Some time in the future we'll want to create
v2.0. As happen with many other projects (think for example in Flex with
v1.0, 2.0, 3.0, 4.0) each major release implies dramatic changes. If you
change from Java 5 to 6, 7, 8, 9...or Spring framework from 2.0, 3.0,
4.0...you know what I'm talking about. So for Royale this dependency design
makes us more flexible and capable to make a 2.0, 3.0, and so on without
affect 1.0 in a hard way, so our users will be less affected and will be
able to upgrade in a more easy way.
8.-Because as I said before, we have the same benefits than before, but now
we have many more. While in the other way we are less flexible, more rigid
and that's worse for Royale.
I think this is the major point of discussion we have, and hope that all
points exposed will be sufficient to show the benefits and advantages of
the dependencies. For me the major point
is that we should not have any library in the tree of dependencies that has
a CSS wiring beads, and that library is mandatory in all Royale
applications. I think that's the main point of problems
and we should fix it. that should be a rule "Mandatory libraries in a
royale application can't have a CSS that wire code (beads)", for that
reason, that part of Basic (controls, components and CSS should be in
their own library Basic.swc, and the reusable code be in a common library
that the rest can use (i.e: Foundation.swc)
Hope this brings more clarity, but I think I'm repeating myself in many
many emails
Thanks
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691173177&sdata=HLPEpA4PpGIMHY9HjRGpI68axR7RAZdW05hbWW%2FeJuc%3D&reserved=0
