Hi Harbs 2018-06-01 11:03 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> 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? > 4. Methodology: Royale should not impose linking of libraries, other that Language, Test and Core. I think yes. Alex and you think no. > > 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. > Don't think so. If you want to promote reusable pieces, the refactor of names should make them go to a different package other than Basic. It's like to propose to put on a jewel package would be a bad decision. In the refactor I was for "core", since the common pieces was in Core. So I think it will depend on the name of the library to choose. For me Basic is a good name for Basic UI Set since clearly states what all the code there do. I still think Foundation is a good name, but if you don't like, I think you should propose other one that seems more appropriate. > 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.) > I think we must be doing it moving little by little and ensuring after a little refactor all continues working. > 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. > Here we have a problem. I think we need to fix things and that should make many problems are gone. But although the problems are gone, we have a different approach in how to build Jewel components for you Jewel Button extends Basic Button, for me Jewel Button extends UIBase... how can we overcome it? For me your option is less flexible than mine, and I give you many arguments, while I don't see any arguments in favor of making Jewel extend Basic TLCs I think that's the problem here. > 4. Let’s complete Jewel and see wether there is a reason to use the > TLCs/CSS. > But, in my previous email I said that If I want to continue working in Jewel components I need to continue moving things to a library shared. So to complete since I don't consider the option of linking Basic how can I perform the completion? Coming code to Jewel? Is not an option for any of us Moving to Core? I think we are still discussing what to do. I only can create Foundation lib and move there, while keeping the same in Basic temporarily and link Foundation to Jewel. If you have some additional way to do this that not implies link Basic let me know. > 5. Let’s do research on whether CSS processing during compilation is an > issue and try and figure out our options if it is. > Imagine you get to fix bugs and fix current CSS so you get rid of all the current problems....Then you prefer to continue in the same way that already was clearly problematic, and will bring more problems later? don't understand why...when you have a simpler and better way that is removing the dependency and it's the most easy and quick way and will preserver the integrity always in the future. > 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. > > Ok, my only concern here is how to do this plan, since I see many problems that only can be making just what I can avoid. > 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 > > -- Carlos Rovira http://about.me/carlosrovira
