Hi Harbs 2018-05-31 15:10 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> 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. > What I said is that we'll need at least "DataGrid" in Jewel SWC, then most of the pieces in Basic will be reused (so I expect it to be in a shared SWC, what I call Foundation). Then DataGridColumnList will be needed in Jewel as well, but extending jewel List. DataGridButtonBar will extend ButtonBar from Jewel, when this exits. For example IDataGridColumn will be taken from Basic as well DataGridModel. DataGridView will be implemented in Jewel So, all that I can reuse, will be reused. No sense to duplicate code if can avoid that. So as you see is not the whole component, is not possible, but I think a decent part will be shared. > > We *would* need to make sure that the swapped view classes are not > imported unnecessarily. That is easy to do making separation. The opposite will be really hard since you'll find here and there points hidden. I didn't see many problems until current separation shows the problems in compilation. I think that can only be accomplished by separation for sure. If not is a finger to the wind ;) > (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. > Right bugs must be fixed, but a fixed bug doesn't mind we should avoid setup things in the right way. We should want to pursue both. > > 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. > The problem I see is that If I want to work on the next component, I'll need to move things from Basic to Core, or make the intermediate Foundation library, if not I'll be duplicating code that is not what we want. The good point is that making Foundation SWC and moving pieces to it as I work on Jewel should not impact current state of Royale, we only need to add the dependency. The rename we plan to do is what will cause users to update code. > > 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 > >> > >> > > > > > > -- Carlos Rovira http://about.me/carlosrovira
