Hi Alex, I found that TodoMVC examples was not working, so I fixed it removing the non existing properties (hoverable and selectable). But I found Jewel ListItemRenderer has all baked, so I created a SimpleListItemRenderer (in Jewel Simple in the normal prefix for a "base", "basic" or "simple" option) that hast the minimum required.
So at least in Jewel if people wants hoverable and selectable renderers use the normal ListItemRenderer. If don't want that indicators, use SimpleListItemRenderer. If you want just show hover, but not selected state, then extend Simple version and add " ClassSelectorListRuntimeSelectableItemRendererBead" and configure to have just "hoverable" to true ¿ok? Hope I understand ok how it works. Let me know if something is not as expected. Thanks Carlos El jue., 20 feb. 2020 a las 18:06, Alex Harui (<[email protected]>) escribió: > I'm not sure I understand what you mean by "control". > > Before the "has" changes, every ItemRenderer contained or inherited code > that had hovered/selected APIs that drew visuals, and the ItemRenderer also > "had" a bead like ItemRendererMouseController that set the hovered property > on that item renderer, and the List's controller would set the selected > property. > > Now, every ItemRenderer "has" a bead that has the hovered/selected > properties, and the ItemRendererMouseController and the Lists's controllers > get that bead instead of talking to the ItemRenderer directly. I guess > that's the new way of thinking for has/composition vs is/inheritance: a > component doesn't have to have all of its APIs glued to its API surface. > We mainly do that for convenience in MXML, but for more internal stuff like > this, loose-coupling via has/composition shared more code and increases > configurability, but does add some runtime overhead in its raw form. > Hopefully we can optimize that away. > > HTH, > -Alex > > On 2/20/20, 5:01 AM, "Piotr Zarzycki" <[email protected]> wrote: > > Hi Alex, > > Could you provide an example how would I control hovering/selecting in > item > renderer when I don't have build in hover property etc. ? How should I > compose such item renderer ? > > Thanks, > Piotr > > czw., 20 lut 2020 o 03:20 Alex Harui <[email protected]> > napisał(a): > > > I pushed the "has" changes. TourDeJewel seems to be working > correctly for > > me. > > > > The principle of "has" is similar to inheritance vs composition. > Just > > like top-level components like List are composed of many beads, the > item > > renderers are now composed of more beads as well. That reduces the > > requirement to add code to a class in order to "be/is" something. > > > > There used to be copies of code that drew hover and selected states > on > > the item renderers in each new kind of item renderer that couldn't > inherit > > from an item renderer that could draw selected and hovered states. > Now, > > the itemrenderers compose their selection visuals. A single item > renderer > > like StringItemRenderer can be composed with no selection drawing at > all, > > or with solid color selection drawing or with alternate color > selection > > drawing or something new. And that means that some new kind of > item > > renderer, like a TextInput can become an item renderer more easily, > by > > composing a selection visuals bead instead of having to add all of > that > > code. > > > > Another place I started using "has" but didn't fully replace the old > code > > was in handling itemRendererParent, which is now called > > itemRendererOwnerView (to try to make it more clear that isn't > always the > > parent of the item renderer and is sometimes an internal > > datagroup/container). Turns out a lot of our renderers didn't need > to know > > the itemRendererParent, so in many cases we no longer figure it out > and > > assign it. But in cases where it is needed, the property is > currently left > > baked into the renderer, but in some new cases, it is composed. An > > ItemRendererOwnerViewBead is added to the strand instead of added to > a > > class and contains the reference to the ownerView. Maybe someday > we'll > > fully remove the old pattern, not sure. > > > > Ideally we would do more "has" than "is". It could allow us to > eliminate > > much of the required code to be a top tag in an MXML document. > > > > Other changes in this branch were to add "Initializers" so the > > RendererFactories didn't bake in code for specific item renderers, > and to > > create a few base classes with overrides so there is less code to > maintain. > > > > There should be little if any impact to application code. It should > > mainly affect the internals of how item renderer-based things are > created. > > > > Thanks, > > -Alex > > > > On 2/17/20, 4:33 PM, "Carlos Rovira" <[email protected]> > wrote: > > > > Hi Alex, > > > > if will be of help if you point us to different links where we > can > > learn > > about this modifications, since I at least can just imagine what > is all > > about, but will need to get deeper in the concepts to understand > the > > changes and to apply this patterns. > > > > In Jewel each "list component has its own type of renderer, so > for > > example > > List uses ListItemRenderer and DataGrid has > DataGridItemRenderer, since > > usually at that component level the user needs similar > infrastructure > > like > > hoverable, selectable...and some (not much) more, don't know > right now > > how > > all this will fit with the "has" new pattern....I'll try it. > > > > Just one important thing. There's actual users and clients using > Jewel > > and > > other UI sets and are with very short times for their > migrations, so > > just > > want to ask you to test as much as possible, since TDJ has many > > examples > > now. Other thing you can test is new TodoMVC to see how it > behaves, > > since > > it uses a List with IRs. So we can ensure (as much as we can) > the merge > > left things working (as much as we can) > > > > Thanks for working on this, will try all of this tomorrow > > > > Carlos > > > > > > > > > > El lun., 17 feb. 2020 a las 22:35, Alex Harui > > (<[email protected]>) > > escribió: > > > > > I've pushed the "has" branch that contains a refactoring of > the item > > > renderers. Tour De Jewel and MDL Example seem to be working > as is > > Basic > > > List Example and MX AdvancedDataGrid. > > > > > > "has" is really just calls to getBeadByType. If we start to > see > > > performance issues, then we'll look into optimizing. The > motivation > > to > > > switch to "has" came from several bugs about using MX > Label/CheckBox > > as > > > item renderers. In Royale, the ItemRenderers were in control > of the > > > visuals of their rollover and selected state. That is a more > proper > > > encapsulation than the way it was in Flex where the lists drew > the > > rollover > > > and selected states and it was hard to override the visuals > for a > > custom > > > item renderer. But in the develop branch Royale code, it would > > require > > > that custom itemrenderers implement a lot of APIs related to > > rollover and > > > selected visuals. Instead we can now reuse/share code for > visuals > > between > > > different renderers because a renderer now can "has" a > > rollover/selection > > > implementation instead of being one. > > > > > > There are more pieces involved, but there is more sharing of > code. > > Along > > > the way I found that there were some not-so-PAYG patterns > being used > > in MDL > > > and Jewel renderers that might deserve further modification. > There > > are > > > "hoverable" and "selectable" APIs that appear to be used to > > permanently > > > turn off selection and hover visuals. In general, I think > there is > > better > > > use of PAYG and composition when functionality is "built up" > and not > > > "turned off", so with the "has" pattern the renderers can be > added > > to a > > > list without any selection visuals at all (for a non-selectable > > list) or > > > re-composed with custom visuals that only support hoverable, > for > > example. > > > I left it "hoverable/selectable" in the API surface for now, > but > > something > > > to think about going forward. > > > > > > I’m going to run a few more tests before merging and pushing to > > develop. > > > > > > -Alex > > > > > > On 1/15/20, 10:44 PM, "Alex Harui" <[email protected]> > wrote: > > > > > > You are welcome to try and see how many cache hits it > gets. I > > think > > > in renderers, we ask once per renderer. I'm not sure there is > a > > faster way > > > to do the first lookup of "is", but for "has" we could change > the > > lookup > > > and save time. > > > > > > On 1/15/20, 10:38 PM, "Greg Dove" <[email protected]> > wrote: > > > > > > For the 'something is ISomeInterface' > > > I had wondered in the past if these types of lookups > could be > > > incrementally > > > cached on the 'is' target (after first lookup), that > might > > make > > > sense for > > > interfaces, which are the deepest checks I think? > > > caching result (could optionally create the Map) > > > ISomeInterface['implMap'].set(something.constructor, > > isResult ) > > > > > > then earlier in the interface checks, it could do > something > > like: > > > if (ISomeInterface['implMap'] && > > > ISomeInterface['implMap'].has(something.constructor) ) > return > > > ISomeInterface['implMap'].get(something.constructor) > > > > > > I realize its extra code, but it should be quite a bit > > faster over > > > time I > > > think. > > > > > > On Thu, Jan 16, 2020 at 7:20 PM Alex Harui > > > <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > Several different threads have brought up issues with > > sharing > > > code between > > > > component sets. Other threads have offered > different and > > clever > > > ways to > > > > do various things like how MXML is applied to a > component. > > > Meanwhile, over > > > > in MX emulation, I was starting to copy some code > from > > Basic to > > > MXRoyale to > > > > get the various MX components to be valid item > renderers. > > > MXRoyale is > > > > using Basic's item renderer architecture which is > better > > > encapsulated: the > > > > renderer draws its hovered and selected state. In > Flex, > > the > > > List draws > > > > over the renderer, which makes it hard to customize > the > > way the > > > renderer > > > > will look when hovered and selected. > > > > > > > > It finally occurred to me that one of the reasons we > end up > > > copying code > > > > is because we are still using too many "is" checks > instead > > of > > > "has" > > > > checks. I'm not even sure we have any "has" checks > in the > > Royale > > > > framework. I was afraid of the overhead of a "has" > check, > > but > > > I'm starting > > > > to change my mind because: > > > > > > > > 1) The "is" check actually runs a fair amount of > code, > > > especially for > > > > (comp is ISomeInterface) > > > > 2) The length of bead arrays don't seem too long. > > > > > > > > A "has" check calls getBeadByType(ISomeInterface), > so it > > > actually will run > > > > the (bead is ISomeInterface) on potentially the > entire > > strand > > > array/vector, > > > > although we could speed that up by annotating beads > or > > keeping > > > track of > > > > what is on the strand. But the code sharing/reuse > > potential of > > > this > > > > pattern seems significant to me. > > > > > > > > For example, it could change how hard it is to make a > > component > > > usable as > > > > a top tag in MXML. Instead of the component having > to > > implement > > > certain > > > > methods, the component could have a bead installed > and the > > > > MXMLDataInterpreter could talk to that bead instead > of the > > > component. > > > > > > > > In the case of the item renderers, instead of > testing if > > the > > > renderer "is" > > > > ISelectableLIstItemRenderer, it could ask if the > created > > widget > > > "has" an > > > > ISelectableLIstItemRenderer bead and the logic in > that > > bead can > > > be reused > > > > in both Basic and MXRoyale without being copied. > > > > > > > > Some code, like Container overrides of addElement > probably > > can't > > > be > > > > refactored into a "has". But I wonder how many other > > things > > > could. I'm > > > > not sure I would move everything that could be moved > into a > > > shared bead. > > > > We'd have to think about the overhead on small > components > > and > > > apps. But > > > > for MXML support and Item Renderer support, it seems > to > > make > > > sense. > > > > > > > > Anyway, I will look into refactoring the item > renderer > > code in > > > a few days > > > > unless feedback indicates otherwise. Bugs like #676 > and > > #681 > > > inspired this > > > > post. > > > > > > > > Of course, I could be wrong... > > > > -Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca9d6e0c66e0e49d3d95408d7b6050a45%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178005075724458&sdata=ETD3FdbrtNaQNgB9VjO7aqNefpT%2FZskBVEXqwSu2pls%3D&reserved=0 > > > > > > > > -- > > Piotr Zarzycki > > Patreon: * > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca9d6e0c66e0e49d3d95408d7b6050a45%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178005075724458&sdata=Fea7D5yfPoUFcMU4eWHB%2F1z21bBbSXXr0kWr1jlhNAY%3D&reserved=0 > < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca9d6e0c66e0e49d3d95408d7b6050a45%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178005075724458&sdata=Fea7D5yfPoUFcMU4eWHB%2F1z21bBbSXXr0kWr1jlhNAY%3D&reserved=0 > >* > > > -- Carlos Rovira http://about.me/carlosrovira
