Hi Carlos, Let me try and summarize in a nutshell the difference of opinion.
1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I think yes. 2. Can we reach a point that by fixing all issues, there will be no runtime penalty of making Basic TLCs a dependency? You think no. Alex and I think yes. 3. Is there an issue with having to process Basic CSS during compilation and if yes can this be avoided? No-one has data on this yet. You think likely yes. I think likely no. Neither one of us really know the answer to this question. I think that’s the sum total of the disagreement here. Agree? I’d like to propose the following way forward. 1. Both Basic (Foundation) pieces and Basic TLCs should have the same package paths and namespaces. 2. By doing this, it will be very painless to pull Basic TLCs out of Basic into a separate project or merge it back in. (i.e. BasicComponents) (Either now, or in the future.) 3. Give Alex and me an opportunity to fix all issues and demonstrate that there will be no tax by making Basic TLCs a dependency. 4. Let’s complete Jewel and see wether there is a reason to use the TLCs/CSS. 5. Let’s do research on whether CSS processing during compilation is an issue and try and figure out our options if it is. 6. If we can’t make all the pieces of Basic truly optional, I’ll help you pull the Basic TLCs and CSS out into a separate project. Would this be acceptable? Thanks, Harbs > On Jun 1, 2018, at 11:25 AM, Carlos Rovira <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 > http://about.me/carlosrovira
