Hi Alex, 2018-06-04 20:15 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> 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. > Right > 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. > Right > 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? Thanks > > 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%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636634383741019830&sdata=fwtYo76SgK6192czpWyQzdMv% > 2B8Y3fcSZd62j1iu%2B8qs%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
