Hi Carlos,
I'm replying to all posts on this thread since my last post.
I see a claim that there is a problem because of the compiler parsing a CSS
file from a SWC where that CSS will not be used. Is there proof that it is a
significant performance problem? Such a claim should be backed by data from an
experiment by making the Basic defaults.css one blank line and see if compile
time of a Jewel-only example speeds up in a significant way. Also, we already
have an -exclude-defaults-css-files option. It currently does not prevent
parsing of the CSS file, but we could make it so. As of last week or so, I
believe the royale-compiler develop branch contains all fixes that caused
unused selectors from themes ending up in the final app. I believe we still
need a volunteer to change the royale-asjs code to eliminate use of class
selectors in its defaults.css files.
In a composition-based component framework, a dependency graph that looks like
it is hierarchical should not be a goal. We want these beads, even high level
beads, to be re-usable in multiple components sets. There may be a SuperJewel
someday or variants on Jewel with completely different names that borrow beads
from Jewel under the principle of re-using code. The Emulation set will
probably use Jewel views. Our users have asked for our component sets to
require little configuration, so Jewel should re-use Express beads.
The beads should be collected into SWCs that organize what they do, much like
Apache Commons. I don’t think Java projects try to only use one Apache Commons
JAR because of a cleaner dependency graph.
I think you are making the argument for doubling the number of SWCs so that
beads go in a SWC and TLCs that use those beads go in a separate SWC. If
that's what folks want to do, that's fine, but I don't think that will be the
right decision. It will mean you have to list two things in each pom.xml
instead of one. It will take longer for component developers to go back and
fix something in the bead project and then in the TLC project. Third-parties
have to deploy two SWCs. Folks can't just grab a SWC and use it, they have to
grab two.
Again think about the analogy of Apache Commons. It is not one giant library,
but a set of libraries. And for sure, if you only use one method out of seven
different Commons libraries the compiler spent time reading the entirety of
those 7 libraries, but you don't want to make the libraries too fine-grained
either. Libraries are organized by common traits to help users figure out
which ones to use, not an attempt to save compile time.
The key is that things not needed don't end up in the output. There isn't an
Apache Commons analogy for that since JARs are dynamically linked. But in
statically-linked libraries like C/C++ on Windows, the compiler does visit
entire libraries and only links in what is needed.
I did notice a good point about code hinting in the IDEs. IMO, the new IDEs
will need to have smarter filtering of the options. We need to think big,
where lots of people are putting lots of SWCs on the various library-paths.
Those of us who are currently committers are likely to only write a small
fraction of the SWCs in the world in Royale is successful. Unlike Flex, where
we tried to get everyone to use MX or Spark, folks should have many more
choices. Flash Builder already has the option of disabling SWCs in a
library-path. I would encourage the IDE vendors to do the same. And also
realize that the MXML manifests allow mapping of a bead from one SWC into
another MXML namespace, so I think folks should be encouraged to filter by
typing the prefix of their active MXML namespaces first and then "Button".
Core used to contain UIBase, ListBase, GroupBase and some other base
implementations of interfaces. Then they moved to Basic during the wrapped
Sprite experiment and never moved back. So, I didn't have any problem with
them moving back just now. The reason they were in Core was to serve as a
starting point for TLCs in other component sets. Again, the key principle is
code reuse. If someone wants to do something very different and unrelated to
the Flex-like nature of our main component sets, they can use those base
classes. But if more folks want to keep them in Basic I'm fine with that.
One closing comment: The reason I think we are picky about the code in Jewel
is because we want it to be the flagship component set for Royale (and I think
we all thank you for getting the visuals to look so good) and thus it "must"
display our recommended practices. MDL and CreateJS will not receive the same
scrutiny. Anyone is welcome to create some other component set that isn't PAYG
at all. But the ones we are promoting as examples (Basic, Express, Jewel)
should reflect our best practices.
My 2 cents,
-Alex
On 5/29/18, 10:52 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi Alex,
2018-05-30 5:53 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> FWIW, I think there is still a disconnect here.
Right, I think we are mostly on consensus about refactoring names and
packages and how to deal with CSS names, but the final point (maybe most
important) is about the dependency library that I think is very important.
> 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.
maybe this is the problem
> 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 that's exactly my concern here. As you said, we don't need every
component set to use a concrete layer, but in the old set up and for Harbs
diagram, we are forcing every single user to do that, and even worse, we
are putting a CSS configuration processing in the middle and making all
apps pas through it. And I write many points about the disadvantages of
doing that. So I think we are saying the same.
> So maybe we should put this thread on pause and finish up that discussion.
>
I think we are reaching to a close here, don't see the need to make a
pause. More over, we have many users out there that wants to try Jewel and
they are waiting for the 0.9.3 release to put blog examples in practice. I
think we are gaining some momentum out there, and that was hard work to
reach to that. We are pausing this efforts and if we don't feed the
external communication, that will end reverting that effort. So I think is
better to go forward and solve this problem. We are about a month stuck
here, and that's not good for the project IMHO.
>
> 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.
Again we are saying the same, the latter beads, the concrete
implementations of controls and components, and the CSS that wires all,
should go to its own optional library (i.e: Basic, Jewel,...) for the user
to choose the one to use without obligation for our part.
> Yet Component Sets are welcome and even encouraged to leverage these more
> complex beads. Our users have asked for that.
>
Right.
>
> - 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.
>
I'm as well aligned with this. This is ok with the new dependency of
libraries
IMHO, we have consensus in all the things discussed in the other threads,
and regarding dependency of libraries, I see for this email that Alex and I
are saying the same and only need to know about Harbs.
Maybe since both ways do the same, the question you must to answer yourself
is: Do I want to have all the same benefits from old configuration, plus
new flexibility ones? hope the answer will be yes
thanks
>
> 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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632137691163168&sdata=A1StIlX4vcrkQ%
> 2F8EF7o8SPoGD28pmyHp6amM%2BzYQqNI%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7Ca0c7ac59b92743f83ac808d5c5f1821f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632563492435870&sdata=I4u9xUDRERMVsM1mZWfNKIfLfsE1KAUoClDJEj8BoW4%3D&reserved=0.
> protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%
> 2FDbH4iG.jpg&data=02%7C01%7Caharui%40adobe.com%
> 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632137691173177&sdata=IKoHqY9iflgHix7NbSbw1mO9wptThn
> LbFv7tLFIE4DU%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632137691173177&sdata=HLPEpA4PpGIMHY9HjRGpI68axR7RAZ
> dW05hbWW%2FeJuc%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca0c7ac59b92743f83ac808d5c5f1821f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632563492435870&sdata=hJWNXAekVx6UlgDEmFDrBnU%2FXbSaItFzTb4ESaxL5JI%3D&reserved=0
