Hi Harbs, concreting more over if Jewel should or not extend Basic TLCs. That I think is the real point now to discuss. I'm sure it should not be the case. To sum to all that I exposed, it was not clearly sufficient enough (that I think it should be). Why I want all the class definitions overhead it will cause?
Why have the basic Button file with all the class text definitions and then the jewel Button file with all the definitions there? Think that we don't get anything profitable from all that overhead. I think that reusable code are pieces to construct, but not pieces designed to be final in some case. So to build a house I use bricks, cement, beams, and so on, but then I don't use the house to make a castle. Moreover, think that Basic needs to change some component part...then maybe Jewel can't do that... that's a huge problem. So think that in the house I want to change a window from a place to another, then the castle will need to live with that without any reason and possibility to not be affected. You must to recognize that although the theory here is good (remember that I started to be aligned with that), the reality is not the same. My experience in many things in life make think that not all is 100% black or white. I think is great the philosophy we have on PAYG, beads and reuse, but I the case of TLCs and see that as something optionally extendible, but not mandatory. Or in other words TLCs are almost a leaf usable component that is mainly designed with a concrete end or use, and work great in aggregation (i.e: Express), but should not be part of any mandatory use. It's building blocks, in opposite, (the bricks) need to be enforced to reuse as much as we can. Hope this additional vision will help on the overall discussion. 2018-05-31 10:05 GMT+02:00 Harbs <harbs.li...@gmail.com>: > Comments inline. > > > On May 31, 2018, at 10:44 AM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > I think there's a cost, don't know if the cost is higher or lower. > > My question is whether we would actually be avoiding this cost by pulling > the CSS out of Basic. I don’t know the answer to this question. I suspect > that the compiler needs to analyze all the CSS files in every swc in the > libs folder whether they are used or not. If that’s the case, there’s > nothing to gain by pulling out the CSS for at least 90% of the use cases of > Royale. Almost all Royale users will have the full lib of swcs. > > > To me is > > not only the cost, is about as well as methodology. For me is incorrect > to > > have a CSS always be compiled, no matter what kind of application I'll be > > constructing, even if nothing of that CSS goes into the final > Application. > > You're making a useless compilation, that can introduce bugs or not, or > you > > must keep and eye always that is not doing wrong things. If you don't put > > that CSS in mandatory SWC, your problems are all gone. I think CSS should > > be *always* in optional SWCs. For me maybe this is the most important > > concept or rule we should follow. > > In theory, I agree with you. In practice, I’m not so sure. > > The problem with pulling the TLC components out of Basic is that it > requires a separate dependency for use. That makes more work for someone > using Maven (for example). Also the likelihood of NONE of the TLCs to be > used by other component sets is slim. I believe that Basic (or Express) > composite components (such as ComboBox, DataGrid, etc.) should be used in > Jewel and just the views should be swapped out. Dictating that Jewel can’t > use Basic TLCs simply on principle is something I have a hard time with. > > If using them would have a concrete negative effect on an app, I agree > that it would be a problem, but I think we’ve determined that to not be the > case. > > Thanks, > Harbs > > -- Carlos Rovira http://about.me/carlosrovira
