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%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 http://about.me/carlosrovira
