I’m not sure if we’re communicating. Composite TLCs have many pieces and only some of them are related to View. DataGrid has 5 class reference and only one is IBeadView. DataGrid uses DataGridColumnList which has 9 class references. One is view and another which might (or might not) need replacement is layout. Other than these classes, the whole component should just work as-is in Jewel. All you need is to swap out the IBeadView and/or part of the view.
We *would* need to make sure that the swapped view classes are not imported unnecessarily. (I’m not sure if they are or not.) If they are, I think it’s clear that is a bug which needs to be fixed no-matter. Defaults should not be imported if overridden by applications. Maybe we should wait on this decision until Jewel is more complete? It’s possible that you are right and none of the TLCs will end up in Jewel. It’s possible I’m right and they will. I don’t see how restructuring Basic is necessary until we’re sure of the outcome of that. Thoughts? Harbs > On May 31, 2018, at 2:10 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > >> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly >> ImageButon etc. The components are basically UIBase components which >> describe how the pieces are wired together. The views are separate >> components that are declared. For these TLCs, there shouldn’t be a need to >> duplicate the classes or subclass the classes in Jewel at all. It should be >> possible to simply use Basic or Express composite TLCs and simply declare a >> Jewel view to use with them. >> >> > yes, if you are seeing that the compositing TLCs are Jewel TLCs. For > example, ComboBox will compose a Jewel Button not Basic Button, to comply > with the overall set and purpose. As well will compose a TextInput and a > List from Jewel, not from Basic. Take into account that the first thing a > Jewel TLC (basic or complex) will do is set typeNames in constructor to > "jewel XXX", and then define "component parts" like button:Button (of Jewel > set). > > Image Button will as well composite a Jewel Button. DataGrid is a complex > TLC that will be using jewel TLCs and other build blocks currently in > Basic, that should move to Foundation (or whatever we want to call to > "reusable library with common code and beads"). > > What is clear is that all pieces that are reusable in ComboBox, DataGrid or > ImageButton will be used to create those components in Jewel, as many as we > can. > All those components will have its own Jewel view to make its own visuals, > like SliderView in jewel needs that code that is different to basic one > since it "fills" the bar as we move the thumb. > > > >> Is there an issue that I’m missing here? >> >> Harbs >> >>> On May 31, 2018, at 12:12 PM, Carlos Rovira <carlosrov...@apache.org> >> wrote: >>> >>> 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 >> >> > >
