You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2020/01/16 06:20:23 UTC
"has" vs "is": sharing code, swapping out subsystems, and more...
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
Re: "has" vs "is": sharing code, swapping out subsystems, and
more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Currently "has" is getBeadByType(ISomeInterface). I personally don't want to spend the energy adding a new keyword to the language. Also, this kind of "has" is not the same as "hasOwnProperty". This is more about composition, not what properties exist.
My first proposal for optimization is to create Language.has as a utility function that we could later optimize. getBeadByType must always scan the strand and use "is", but Language.has can try caching, or a faster test, such as assuming that beads that support "has" will support some sort of id map API that can be queried in a try/catch. That might be faster than sequential "is" checks.
-Alex
On 1/16/20, 7:05 AM, "Harbs" <ha...@gmail.com> wrote:
I like the idea of a “has”. What would the syntax be and how would it work?
I’d love to be able to write if(foo has Baz) (and that would be compiled to something like if(Language.has(foo,Baz))
I’d also guess that it would loop through the list of beads and test “is” on all of them. For positive results, I think we could make that fast with a cached lookup after the first time, but for failed checks, I imagine it would be quite slow.
> On Jan 16, 2020, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID> 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
>
Re: "has" vs "is": sharing code, swapping out subsystems, and
more...
Posted by Harbs <ha...@gmail.com>.
I like the idea of a “has”. What would the syntax be and how would it work?
I’d love to be able to write if(foo has Baz) (and that would be compiled to something like if(Language.has(foo,Baz))
I’d also guess that it would loop through the list of beads and test “is” on all of them. For positive results, I think we could make that fast with a cached lookup after the first time, but for failed checks, I imagine it would be quite slow.
> On Jan 16, 2020, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID> 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
>
hasOwnProperty() not working ( was Re: "has" vs "is": sharing code,
swapping out subsystems, and more...)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Yishay,
can you share some code declaration example so I can try something similar?
I think the code I tried was this (can ensure 100%): if(!(_strand as
Object).hasOwnProperty("datagrid"))
for a Strand that is a normal Jewel List (that is not IDataGridColumnList,
the only one that supports "datagrid" property) the if block was executed.
So the if block was executing in all cases.
So I figured this was not supported right as in Flash or was a bug, although
if we are trying to support AS3 right that should be working fine.
Thanks
Carlos
El jue., 16 ene. 2020 a las 19:10, Yishay Weiss (<yi...@hotmail.com>)
escribió:
> We do use [1] hasOwnProperty(). What went wrong? Maybe this needs to be
> in a different thread though, because the original thread is more about a
> getBeadByType() search.
>
> [1]
> https://github.com/apache/royale-asjs/blob/781c2ed44f7f64110fd011b617949c1faae5f158/frameworks/projects/MXRoyale/src/main/royale/mx/charts/renderers/CircleItemRenderer.as#L141
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, January 16, 2020 11:50 AM
> To: dev@royale.apache.org<ma...@royale.apache.org>
> Subject: Re: "has" vs "is": sharing code, swapping out subsystems, and
> more...
>
> Hi,
>
> recently I want to do a "has" instead of "is", but I couldn't.
> I'm not talking about at "bead" level, just something like we use to do in
> Flash (hasOwnProperty)
>
> Taking the code in [1]. I'd like to change this
>
> if(!(_strand is IDataGridColumnList))
>
> for something like this
>
> if(_strand.hasOwnProperty("datagrid"))
>
> in order to avoid check against the IDataGridColumnList interface, that
> users using List but not using DataGrid, will not need to compile in his
> apps (adding all that datagrid code burden)
>
>
> [1]
>
> https://github.com/apache/royale-asjs/blob/56dbe7a33e66f104a882654ce00c7a1074296725/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/beads/itemRenderers/AddListItemRendererForArrayListData.as#L154
>
> --
Carlos Rovira
http://about.me/carlosrovira
RE: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Yishay Weiss <yi...@hotmail.com>.
We do use [1] hasOwnProperty(). What went wrong? Maybe this needs to be in a different thread though, because the original thread is more about a getBeadByType() search.
[1] https://github.com/apache/royale-asjs/blob/781c2ed44f7f64110fd011b617949c1faae5f158/frameworks/projects/MXRoyale/src/main/royale/mx/charts/renderers/CircleItemRenderer.as#L141
From: Carlos Rovira<ma...@apache.org>
Sent: Thursday, January 16, 2020 11:50 AM
To: dev@royale.apache.org<ma...@royale.apache.org>
Subject: Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Hi,
recently I want to do a "has" instead of "is", but I couldn't.
I'm not talking about at "bead" level, just something like we use to do in
Flash (hasOwnProperty)
Taking the code in [1]. I'd like to change this
if(!(_strand is IDataGridColumnList))
for something like this
if(_strand.hasOwnProperty("datagrid"))
in order to avoid check against the IDataGridColumnList interface, that
users using List but not using DataGrid, will not need to compile in his
apps (adding all that datagrid code burden)
[1]
https://github.com/apache/royale-asjs/blob/56dbe7a33e66f104a882654ce00c7a1074296725/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/beads/itemRenderers/AddListItemRendererForArrayListData.as#L154
El jue., 16 ene. 2020 a las 7:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> 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" <gr...@gmail.com> 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 <ah...@adobe.com.invalid>
> 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
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
recently I want to do a "has" instead of "is", but I couldn't.
I'm not talking about at "bead" level, just something like we use to do in
Flash (hasOwnProperty)
Taking the code in [1]. I'd like to change this
if(!(_strand is IDataGridColumnList))
for something like this
if(_strand.hasOwnProperty("datagrid"))
in order to avoid check against the IDataGridColumnList interface, that
users using List but not using DataGrid, will not need to compile in his
apps (adding all that datagrid code burden)
[1]
https://github.com/apache/royale-asjs/blob/56dbe7a33e66f104a882654ce00c7a1074296725/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/beads/itemRenderers/AddListItemRendererForArrayListData.as#L154
El jue., 16 ene. 2020 a las 7:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> 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" <gr...@gmail.com> 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 <ah...@adobe.com.invalid>
> 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
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I tried to remove (commit d8ae342bb12e1006caed480dba7e3d91bab589da) and
seems all ok since is managed in the beads.
If is wrong feel free to revert
thanks
El vie., 21 feb. 2020 a las 12:11, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
> thanks for the changes all have more sense that way now.
> One question about Jewel ListItemRenderer.as
> in line 56
> addClass("selectable");
> that should remain?
> I guess it must be removed (like in "NavigationLinkItemRenderer" and "
> TabBarButtonItemRenderer"
> right?
>
> El jue., 20 feb. 2020 a las 23:03, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> I pushed changes that I think has everything working in Jewel by using
>> the same "has" pattern that is used in other component sets.
>>
>> The Lists in the ToDo examples use a regular ItemRendererClassFactory
>> instead of SelectableItemRendererClassFactory that is now used in most
>> other places (List/DataGrid/Table)
>>
>> The recommended pattern for disabling selection in a list is whether you
>> choose a ClassFactory that attaches a Selection Bead to each renderer.
>> There was an exception to that rule in one of the Table examples because it
>> wanted only certain renderers to not have selection. I added a bead that
>> turns off the selection for that case. IMO, how to deal with such an
>> exception will be based more on what percentage of the renderers need
>> selection. If most do, then add a Selection Bead to all renderers but
>> disable selection where you don't want it. If most do not want selection,
>> then add the bead where you need it.
>>
>> Thanks,
>> -Alex
>>
>> On 2/20/20, 11:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> yes, Jewel has the "structure" and is organized in SASS files, then
>> JewelTheme has the "styling" part and is as well SASS.
>> so Jewel should not need to change, and people should only need to
>> change
>> JewelTheme or create a new theme one using it as a template.
>>
>> I'll add examples to ant tomorrow
>>
>> thanks
>>
>>
>> El jue., 20 feb. 2020 a las 20:17, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> escribió:
>>
>> >
>> >
>> > On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >
>> > forgot to say. Can you add missing examples to ANT? don't know
>> where
>> > to do
>> > that
>> > and checking Jewel don't see the use of
>> > SelectableItemRendererClassFactory.
>> > all times ItemRendererClassFactory is used
>> >
>> > I could fix the Ant side, but I don't have time. It think all you
>> need to
>> > do is add it to the examples/build.xml
>> >
>> > I didn't use SelectableItemRendererClassFactory in Jewel because I
>> wasn't
>> > sure if the selection was supposed to be changeable at runtime. I
>> think
>> > you've confirmed that it isn't so we can change to use
>> > SelectableItemRendererClassFactory
>> >
>> > I knew the themes were generated by SASS, but I didn't realize the
>> Jewel
>> > one was as well.
>> >
>> > -Alex
>> >
>> > El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>> > carlosrovira@apache.org>)
>> > escribió:
>> >
>> > > Hi Alex,
>> > >
>> > > remember that Jewel uses SASS to create the CSS. I already
>> pushed a
>> > commit
>> > > with ["warning"]. It's not the first time I warn about it ;)
>> > > You must to change SASS file. The css is just generated (like
>> other
>> > > generations in compiler), and is committed since no body
>> added SASS
>> > to ANT.
>> > > Maven has a sass plugin to compile SASS.
>> > >
>> > > I saw you response and commented there
>> > >
>> > > Thanks
>> > >
>> > > Carlos
>> > >
>> > >
>> > > El jue., 20 feb. 2020 a las 19:55, Alex Harui
>> > (<ah...@adobe.com.invalid>)
>> > > escribió:
>> > >
>> > >> I replied on this topic on your commit email.
>> > >>
>> > >> So I don't have to copy that into this thread, read what I
>> said in
>> > that
>> > >> email and reply on that thread and let's figure out the
>> right thing
>> > to do.
>> > >> I am having some weird problem with my Maven build where
>> every time
>> > I try
>> > >> to change Jewel's defaults.css something overwrites it. I'm
>> trying
>> > to
>> > >> figure out what is going on there.
>> > >>
>> > >> -Alex
>> > >>
>> > >> On 2/20/20, 10:47 AM, "Carlos Rovira" <
>> carlosrovira@apache.org>
>> > wrote:
>> > >>
>> > >> 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
>> > >> (<ah...@adobe.com.invalid>)
>> > >> 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" <
>> > piotrzarzycki21@gmail.com>
>> > >> 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
>> > <ah...@adobe.com.invalid>
>> > >> > 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" <
>> > carlosrovira@apache.org
>> > >> >
>> > >> > 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
>> > >> > > (<ah...@adobe.com.invalid>)
>> > >> > > 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"
>> > >> <ah...@adobe.com.INVALID>
>> > >> > 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" <
>> > >> greg.dove@gmail.com>
>> > >> > 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
>> > >> > > > <ah...@adobe.com.invalid> 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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
>> > >> > <
>> > >> >
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
>> > >> > >*
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> Carlos Rovira
>> > >>
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> > >
>> > >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
thanks for the changes all have more sense that way now.
One question about Jewel ListItemRenderer.as
in line 56
addClass("selectable");
that should remain?
I guess it must be removed (like in "NavigationLinkItemRenderer" and "
TabBarButtonItemRenderer"
right?
El jue., 20 feb. 2020 a las 23:03, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I pushed changes that I think has everything working in Jewel by using the
> same "has" pattern that is used in other component sets.
>
> The Lists in the ToDo examples use a regular ItemRendererClassFactory
> instead of SelectableItemRendererClassFactory that is now used in most
> other places (List/DataGrid/Table)
>
> The recommended pattern for disabling selection in a list is whether you
> choose a ClassFactory that attaches a Selection Bead to each renderer.
> There was an exception to that rule in one of the Table examples because it
> wanted only certain renderers to not have selection. I added a bead that
> turns off the selection for that case. IMO, how to deal with such an
> exception will be based more on what percentage of the renderers need
> selection. If most do, then add a Selection Bead to all renderers but
> disable selection where you don't want it. If most do not want selection,
> then add the bead where you need it.
>
> Thanks,
> -Alex
>
> On 2/20/20, 11:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> yes, Jewel has the "structure" and is organized in SASS files, then
> JewelTheme has the "styling" part and is as well SASS.
> so Jewel should not need to change, and people should only need to
> change
> JewelTheme or create a new theme one using it as a template.
>
> I'll add examples to ant tomorrow
>
> thanks
>
>
> El jue., 20 feb. 2020 a las 20:17, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> >
> >
> > On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > forgot to say. Can you add missing examples to ANT? don't know
> where
> > to do
> > that
> > and checking Jewel don't see the use of
> > SelectableItemRendererClassFactory.
> > all times ItemRendererClassFactory is used
> >
> > I could fix the Ant side, but I don't have time. It think all you
> need to
> > do is add it to the examples/build.xml
> >
> > I didn't use SelectableItemRendererClassFactory in Jewel because I
> wasn't
> > sure if the selection was supposed to be changeable at runtime. I
> think
> > you've confirmed that it isn't so we can change to use
> > SelectableItemRendererClassFactory
> >
> > I knew the themes were generated by SASS, but I didn't realize the
> Jewel
> > one was as well.
> >
> > -Alex
> >
> > El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Hi Alex,
> > >
> > > remember that Jewel uses SASS to create the CSS. I already
> pushed a
> > commit
> > > with ["warning"]. It's not the first time I warn about it ;)
> > > You must to change SASS file. The css is just generated (like
> other
> > > generations in compiler), and is committed since no body added
> SASS
> > to ANT.
> > > Maven has a sass plugin to compile SASS.
> > >
> > > I saw you response and commented there
> > >
> > > Thanks
> > >
> > > Carlos
> > >
> > >
> > > El jue., 20 feb. 2020 a las 19:55, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > >> I replied on this topic on your commit email.
> > >>
> > >> So I don't have to copy that into this thread, read what I
> said in
> > that
> > >> email and reply on that thread and let's figure out the right
> thing
> > to do.
> > >> I am having some weird problem with my Maven build where
> every time
> > I try
> > >> to change Jewel's defaults.css something overwrites it. I'm
> trying
> > to
> > >> figure out what is going on there.
> > >>
> > >> -Alex
> > >>
> > >> On 2/20/20, 10:47 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > wrote:
> > >>
> > >> 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
> > >> (<ah...@adobe.com.invalid>)
> > >> 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" <
> > piotrzarzycki21@gmail.com>
> > >> 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
> > <ah...@adobe.com.invalid>
> > >> > 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" <
> > carlosrovira@apache.org
> > >> >
> > >> > 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
> > >> > > (<ah...@adobe.com.invalid>)
> > >> > > 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"
> > >> <ah...@adobe.com.INVALID>
> > >> > 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" <
> > >> greg.dove@gmail.com>
> > >> > 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
> > >> > > > <ah...@adobe.com.invalid> 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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
> > >> > <
> > >> >
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
> > >> > >*
> > >> >
> > >> >
> > >> >
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
Forgot this for now, I must to rethink a bit. I'll be back when I have more
clear something. Thanks in advance.
Anyway, I think item renderers docs will be very helpful for me and others
Thanks!
El mar., 10 mar. 2020 a las 5:51, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> FWIW, I built TDJ locally on Feb 19 when I pushed the has branch. If I go
> to the ComboBox there is a demo with sliders and the sliders work for me.
> Is that ComboBox virtual or no?
>
> -Alex
> On 3/9/20, 4:54 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> in Jewel ComboBox something is not working as expected for
> ItemRenderers,
> while in VirtualComboBox is working right. I mean rowCount/rowHeight.
> If you check ComboBoxPlayGround in TDJ for an example where those
> properties are set (the one with HSliders), you'll see those
> properties are
> not causing effect. Instead in the VirtualPlayGround a similar
> VirtualComboBox is configured with that properties and works ok.
>
> I think the problem is in the mapper for List, that is different from
> Basic. I can investigate if is a good time to remove jewel mappers now
> that
> renderers are more modular, but I'll need a bit of documentation,
> since I'm
> digging though all the code and is a bit cumbersome to imagine what's
> all
> about.
>
> So could you add some docs to the Itemrenderer royale doc page [1]? I
> think
> it will be of help to me, and others here, and for users too.
>
> Thanks in advance
>
> Carlos
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Ffeatures%2Fitem-renderers&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=j9LG%2FW3EhKlHeWgMr%2FRcfkKFind4I1o3pnu2kGnFVGY%3D&reserved=0
>
>
> El lun., 2 mar. 2020 a las 9:28, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> >
> >
> > On 3/1/20, 11:54 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > Sure. I think separating Selection from the Renderer was the
> right
> > thing to do, but we also need to figure out how to make it do the
> “right
> > thing” be default.
> >
> > I’m wondering if there should be a “selectionBead” property in
> every
> > item renderer which could be null.
> >
> > Maybe DataContainerBase should accept a selectionRenderer
> property the
> > same way it accepts an itemRenderer?
> >
> >
> > I don't know what your scenario really is, so don't have an
> opinion. The
> > SelectableItemRendererClassFactory could look on the List's Strand
> for an
> > instance of a bead that it can use instead of getting the class
> reference
> > from CSS. It depends on where you want to control the configuration
> and
> > why. I'm not sure there will be "one way".
> >
> > An item renderer should probably only have a selectionBead settable
> > property if you can assign different selection beads per renderer,
> not per
> > list, which is probably renderer-specific and not something for the
> base
> > classes.
> >
> > FWIW, DataContainerBase isn't intended to support selection, it is
> just
> > supposed to crank out a bunch of children for a container. The
> Lists are
> > generally where selection becomes optional/required.
> >
> > -Alex
> >
> >
> > > On Mar 2, 2020, at 9:47 AM, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > More loosely-coupled pieces often results in head-scratching.
> But
> > it also results in PAYG and flexibility.
> > >
> > > Our job is to find the common patterns, and pre-compose as
> needed,
> > such as the Express component set. This "has" pattern is a new
> pattern so
> > we'll have to figure out new best practices. And there are probably
> more
> > than one. You might want to override what Selection bead is used
> > >
> > > 1) from some List-level config/attribute/css
> > > 2) in the renderer itself
> > > 3) by some renderer-level config/attribute/css
> > >
> > > IMO, it depends on where you want to control the composition.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
> > >
> > > Yes. If I replace the default
> SelectableItemRendererClassFactory
> > >
> > > My work-around was to use:
> > >
> > > js|List{
> > > IItemRendererClassFactory:
> >
> ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
> > > }
> > >
> > > The average user will be scratching their heads on how to
> solve
> > this problem.
> > >
> > >> On Mar 2, 2020, at 1:19 AM, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > >>
> > >>
> > >>
> > >> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>
> > >> I’ve also discovered that setting the selection bead is more
> > difficult than I would hope it to be.
> > >>
> > >> For example there should be an easy way to specify the
> selection
> > bead in a situation like this:
> > >>
> > >> I may not be understanding the problem. The
> SpreadIconRenderer
> > could have the SelectionBead in its bead list.
> > >>
> > >> -Alex
> > >>
> > >> <js:List
> > >>
> > itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
> > >> height="100%" width="100%"
> > >> >
> > >> <js:beads>
> > >> <js:ArrayListSelectionModel/>
> > >> <js:DataItemRendererFactoryForArrayList/>
> > >> <js:EasyDataProviderChangeNotifier/>
> > >> <js:VScrollViewport id="scrollView"/>
> > >> </js:beads>
> > >>
> > >> </js:List>
> > >>
> > >>> On Mar 1, 2020, at 1:43 AM, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > >>>
> > >>> I've tried two different patterns:
> > >>>
> > >>> 1) ItemRendererOwnerVIew via "has": See
> >
> Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as.
> > Then the ItemRendererClassFactory or the initializer can set it
> > >>>
> > >>> 2) Baking it in where needed and implementing
> > IItemRendererOwnerView and setting it in the initializer.
> > >>>
> > >>> The main "benefit" of this part of the refactor is that not
> all
> > item renderers need to be assigned a host since many don't need it,
> so it
> > is PAYG for those who do. The advantage of the "has" approach is
> that
> > custom item renderers don't add an itemRendererOwnerView property,
> but if
> > the component doesn't allow custom item renderers, might be simpler
> to use
> > approach #2.
> > >>>
> > >>> HTH,
> > >>> -Alex
> > >>>
> > >>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
> > >>>
> > >>> What’s the recommended pattern for getting the “data host”
> from
> > an itemRenderer now that itemRendererParent/itemRendererOwnerView is
> no
> > longer a “thing”?
> > >>>
> > >>> I have the following code in an itemRenderer which inherits
> from
> > DataItemRenderer:
> > >>>
> > >>> (itemRendererParent.host.parent as
> > PagePalette).showMenuHandler(myValueEvent);
> > >>>
> > >>>> On Feb 24, 2020, at 7:02 PM, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > >>>>
> > >>>> It seemed like a separate concern. Right now there are two
> > highly used ItemRendererClassFactory, but several Initializers.
> > >>>>
> > >>>> -Alex
> > >>>>
> > >>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>
> > >>>> Why is IItemRendererInitializer separate from
> > IItemRendererClassFactory?
> > >>>>
> > >>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui
> > <ah...@adobe.com.invalid> wrote:
> > >>>>>
> > >>>>> I pushed changes that I think has everything working in
> Jewel by
> > using the same "has" pattern that is used in other component sets.
> > >>>>>
> > >>>>> The Lists in the ToDo examples use a regular
> > ItemRendererClassFactory instead of
> SelectableItemRendererClassFactory that
> > is now used in most other places (List/DataGrid/Table)
> > >>>>>
> > >>>>> The recommended pattern for disabling selection in a list
> is
> > whether you choose a ClassFactory that attaches a Selection Bead to
> each
> > renderer. There was an exception to that rule in one of the Table
> examples
> > because it wanted only certain renderers to not have selection. I
> added a
> > bead that turns off the selection for that case. IMO, how to deal
> with
> > such an exception will be based more on what percentage of the
> renderers
> > need selection. If most do, then add a Selection Bead to all
> renderers but
> > disable selection where you don't want it. If most do not want
> selection,
> > then add the bead where you need it.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Alex
> > >>>>>
> > >>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <
> carlosrovira@apache.org
> > <ma...@apache.org> <mailto:carlosrovira@apache.org
> <mailto:
> > carlosrovira@apache.org>>> wrote:
> > >>>>>
> > >>>>> yes, Jewel has the "structure" and is organized in SASS
> files,
> > then
> > >>>>> JewelTheme has the "styling" part and is as well SASS.
> > >>>>> so Jewel should not need to change, and people should only
> need
> > to change
> > >>>>> JewelTheme or create a new theme one using it as a
> template.
> > >>>>>
> > >>>>> I'll add examples to ant tomorrow
> > >>>>>
> > >>>>> thanks
> > >>>>>
> > >>>>>
> > >>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui
> > (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> > >>>>> escribió:
> > >>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <
> carlosrovira@apache.org
> > <ma...@apache.org>> wrote:
> > >>>>>>
> > >>>>>> forgot to say. Can you add missing examples to ANT? don't
> know
> > where
> > >>>>>> to do
> > >>>>>> that
> > >>>>>> and checking Jewel don't see the use of
> > >>>>>> SelectableItemRendererClassFactory.
> > >>>>>> all times ItemRendererClassFactory is used
> > >>>>>>
> > >>>>>> I could fix the Ant side, but I don't have time. It
> think all
> > you need to
> > >>>>>> do is add it to the examples/build.xml
> > >>>>>>
> > >>>>>> I didn't use SelectableItemRendererClassFactory in Jewel
> > because I wasn't
> > >>>>>> sure if the selection was supposed to be changeable at
> > runtime. I think
> > >>>>>> you've confirmed that it isn't so we can change to use
> > >>>>>> SelectableItemRendererClassFactory
> > >>>>>>
> > >>>>>> I knew the themes were generated by SASS, but I didn't
> realize
> > the Jewel
> > >>>>>> one was as well.
> > >>>>>>
> > >>>>>> -Alex
> > >>>>>>
> > >>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> > >>>>>> carlosrovira@apache.org <mailto:carlosrovira@apache.org
> >>)
> > >>>>>> escribió:
> > >>>>>>
> > >>>>>>> Hi Alex,
> > >>>>>>>
> > >>>>>>> remember that Jewel uses SASS to create the CSS. I
> already
> > pushed a
> > >>>>>> commit
> > >>>>>>> with ["warning"]. It's not the first time I warn about
> it ;)
> > >>>>>>> You must to change SASS file. The css is just generated
> (like
> > other
> > >>>>>>> generations in compiler), and is committed since no body
> added
> > SASS
> > >>>>>> to ANT.
> > >>>>>>> Maven has a sass plugin to compile SASS.
> > >>>>>>>
> > >>>>>>> I saw you response and commented there
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>>
> > >>>>>>> Carlos
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
> > >>>>>> (<aharui@adobe.com.invalid <mailto:
> aharui@adobe.com.invalid>>)
> > >>>>>>> escribió:
> > >>>>>>>
> > >>>>>>>> I replied on this topic on your commit email.
> > >>>>>>>>
> > >>>>>>>> So I don't have to copy that into this thread, read
> what I
> > said in
> > >>>>>> that
> > >>>>>>>> email and reply on that thread and let's figure out the
> right
> > thing
> > >>>>>> to do.
> > >>>>>>>> I am having some weird problem with my Maven build where
> > every time
> > >>>>>> I try
> > >>>>>>>> to change Jewel's defaults.css something overwrites
> it. I'm
> > trying
> > >>>>>> to
> > >>>>>>>> figure out what is going on there.
> > >>>>>>>>
> > >>>>>>>> -Alex
> > >>>>>>>>
> > >>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <
> > carlosrovira@apache.org <ma...@apache.org>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> 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
> > >>>>>>>> (<aharui@adobe.com.invalid <mailto:
> aharui@adobe.com.invalid
> > >>)
> > >>>>>>>> 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" <
> > >>>>>> piotrzarzycki21@gmail.com <mailto:
> piotrzarzycki21@gmail.com>>
> > >>>>>>>> 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
> > >>>>>> <aharui@adobe.com.invalid <mailto:
> aharui@adobe.com.invalid>>
> > >>>>>>>>> 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" <
> > >>>>>> carlosrovira@apache.org <ma...@apache.org>
> > >>>>>>>>>
> > >>>>>>>>> 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
> > >>>>>>>>>> (<aharui@adobe.com.invalid <mailto:
> aharui@adobe.com.invalid
> > >>)
> > >>>>>>>>>> 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"
> > >>>>>>>> <aharui@adobe.com.INVALID <mailto:
> aharui@adobe.com.INVALID>>
> > >>>>>>>>> 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" <
> > >>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
> > >>>>>>>>> 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
> > >>>>>>>>>>> <aharui@adobe.com.invalid <mailto:
> aharui@adobe.com.invalid>>
> > 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%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%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%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > >>>
> > >>>>>>>>> <
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> > >>>
> > >>>>>>>>>> *
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Carlos Rovira
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > >>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Carlos Rovira
> > >>>>>>>
> > >>>>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > >>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Carlos Rovira
> > >>>>>>
> > >>>>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > >>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Carlos Rovira
> > >>>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >>
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725649667&sdata=z4NUk9PMRcAxzHa6RY%2FYvfFUXIgt9xVL3RZyV9oRFjY%3D&reserved=0
> > >>>
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725649667&sdata=z4NUk9PMRcAxzHa6RY%2FYvfFUXIgt9xVL3RZyV9oRFjY%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I built TDJ locally on Feb 19 when I pushed the has branch. If I go to the ComboBox there is a demo with sliders and the sliders work for me. Is that ComboBox virtual or no?
-Alex
On 3/9/20, 4:54 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
in Jewel ComboBox something is not working as expected for ItemRenderers,
while in VirtualComboBox is working right. I mean rowCount/rowHeight.
If you check ComboBoxPlayGround in TDJ for an example where those
properties are set (the one with HSliders), you'll see those properties are
not causing effect. Instead in the VirtualPlayGround a similar
VirtualComboBox is configured with that properties and works ok.
I think the problem is in the mapper for List, that is different from
Basic. I can investigate if is a good time to remove jewel mappers now that
renderers are more modular, but I'll need a bit of documentation, since I'm
digging though all the code and is a bit cumbersome to imagine what's all
about.
So could you add some docs to the Itemrenderer royale doc page [1]? I think
it will be of help to me, and others here, and for users too.
Thanks in advance
Carlos
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Ffeatures%2Fitem-renderers&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=j9LG%2FW3EhKlHeWgMr%2FRcfkKFind4I1o3pnu2kGnFVGY%3D&reserved=0
El lun., 2 mar. 2020 a las 9:28, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 3/1/20, 11:54 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Sure. I think separating Selection from the Renderer was the right
> thing to do, but we also need to figure out how to make it do the “right
> thing” be default.
>
> I’m wondering if there should be a “selectionBead” property in every
> item renderer which could be null.
>
> Maybe DataContainerBase should accept a selectionRenderer property the
> same way it accepts an itemRenderer?
>
>
> I don't know what your scenario really is, so don't have an opinion. The
> SelectableItemRendererClassFactory could look on the List's Strand for an
> instance of a bead that it can use instead of getting the class reference
> from CSS. It depends on where you want to control the configuration and
> why. I'm not sure there will be "one way".
>
> An item renderer should probably only have a selectionBead settable
> property if you can assign different selection beads per renderer, not per
> list, which is probably renderer-specific and not something for the base
> classes.
>
> FWIW, DataContainerBase isn't intended to support selection, it is just
> supposed to crank out a bunch of children for a container. The Lists are
> generally where selection becomes optional/required.
>
> -Alex
>
>
> > On Mar 2, 2020, at 9:47 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > More loosely-coupled pieces often results in head-scratching. But
> it also results in PAYG and flexibility.
> >
> > Our job is to find the common patterns, and pre-compose as needed,
> such as the Express component set. This "has" pattern is a new pattern so
> we'll have to figure out new best practices. And there are probably more
> than one. You might want to override what Selection bead is used
> >
> > 1) from some List-level config/attribute/css
> > 2) in the renderer itself
> > 3) by some renderer-level config/attribute/css
> >
> > IMO, it depends on where you want to control the composition.
> >
> > My 2 cents,
> > -Alex
> >
> > On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > Yes. If I replace the default SelectableItemRendererClassFactory
> >
> > My work-around was to use:
> >
> > js|List{
> > IItemRendererClassFactory:
> ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
> > }
> >
> > The average user will be scratching their heads on how to solve
> this problem.
> >
> >> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >>
> >>
> >> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>
> >> I’ve also discovered that setting the selection bead is more
> difficult than I would hope it to be.
> >>
> >> For example there should be an easy way to specify the selection
> bead in a situation like this:
> >>
> >> I may not be understanding the problem. The SpreadIconRenderer
> could have the SelectionBead in its bead list.
> >>
> >> -Alex
> >>
> >> <js:List
> >>
> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
> >> height="100%" width="100%"
> >> >
> >> <js:beads>
> >> <js:ArrayListSelectionModel/>
> >> <js:DataItemRendererFactoryForArrayList/>
> >> <js:EasyDataProviderChangeNotifier/>
> >> <js:VScrollViewport id="scrollView"/>
> >> </js:beads>
> >>
> >> </js:List>
> >>
> >>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>
> >>> I've tried two different patterns:
> >>>
> >>> 1) ItemRendererOwnerVIew via "has": See
> Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as.
> Then the ItemRendererClassFactory or the initializer can set it
> >>>
> >>> 2) Baking it in where needed and implementing
> IItemRendererOwnerView and setting it in the initializer.
> >>>
> >>> The main "benefit" of this part of the refactor is that not all
> item renderers need to be assigned a host since many don't need it, so it
> is PAYG for those who do. The advantage of the "has" approach is that
> custom item renderers don't add an itemRendererOwnerView property, but if
> the component doesn't allow custom item renderers, might be simpler to use
> approach #2.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>> What’s the recommended pattern for getting the “data host” from
> an itemRenderer now that itemRendererParent/itemRendererOwnerView is no
> longer a “thing”?
> >>>
> >>> I have the following code in an itemRenderer which inherits from
> DataItemRenderer:
> >>>
> >>> (itemRendererParent.host.parent as
> PagePalette).showMenuHandler(myValueEvent);
> >>>
> >>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>>
> >>>> It seemed like a separate concern. Right now there are two
> highly used ItemRendererClassFactory, but several Initializers.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>
> >>>> Why is IItemRendererInitializer separate from
> IItemRendererClassFactory?
> >>>>
> >>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui
> <ah...@adobe.com.invalid> wrote:
> >>>>>
> >>>>> I pushed changes that I think has everything working in Jewel by
> using the same "has" pattern that is used in other component sets.
> >>>>>
> >>>>> The Lists in the ToDo examples use a regular
> ItemRendererClassFactory instead of SelectableItemRendererClassFactory that
> is now used in most other places (List/DataGrid/Table)
> >>>>>
> >>>>> The recommended pattern for disabling selection in a list is
> whether you choose a ClassFactory that attaches a Selection Bead to each
> renderer. There was an exception to that rule in one of the Table examples
> because it wanted only certain renderers to not have selection. I added a
> bead that turns off the selection for that case. IMO, how to deal with
> such an exception will be based more on what percentage of the renderers
> need selection. If most do, then add a Selection Bead to all renderers but
> disable selection where you don't want it. If most do not want selection,
> then add the bead where you need it.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org
> <ma...@apache.org> <mailto:carlosrovira@apache.org <mailto:
> carlosrovira@apache.org>>> wrote:
> >>>>>
> >>>>> yes, Jewel has the "structure" and is organized in SASS files,
> then
> >>>>> JewelTheme has the "styling" part and is as well SASS.
> >>>>> so Jewel should not need to change, and people should only need
> to change
> >>>>> JewelTheme or create a new theme one using it as a template.
> >>>>>
> >>>>> I'll add examples to ant tomorrow
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>>
> >>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui
> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>>> escribió:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org
> <ma...@apache.org>> wrote:
> >>>>>>
> >>>>>> forgot to say. Can you add missing examples to ANT? don't know
> where
> >>>>>> to do
> >>>>>> that
> >>>>>> and checking Jewel don't see the use of
> >>>>>> SelectableItemRendererClassFactory.
> >>>>>> all times ItemRendererClassFactory is used
> >>>>>>
> >>>>>> I could fix the Ant side, but I don't have time. It think all
> you need to
> >>>>>> do is add it to the examples/build.xml
> >>>>>>
> >>>>>> I didn't use SelectableItemRendererClassFactory in Jewel
> because I wasn't
> >>>>>> sure if the selection was supposed to be changeable at
> runtime. I think
> >>>>>> you've confirmed that it isn't so we can change to use
> >>>>>> SelectableItemRendererClassFactory
> >>>>>>
> >>>>>> I knew the themes were generated by SASS, but I didn't realize
> the Jewel
> >>>>>> one was as well.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> >>>>>> carlosrovira@apache.org <ma...@apache.org>>)
> >>>>>> escribió:
> >>>>>>
> >>>>>>> Hi Alex,
> >>>>>>>
> >>>>>>> remember that Jewel uses SASS to create the CSS. I already
> pushed a
> >>>>>> commit
> >>>>>>> with ["warning"]. It's not the first time I warn about it ;)
> >>>>>>> You must to change SASS file. The css is just generated (like
> other
> >>>>>>> generations in compiler), and is committed since no body added
> SASS
> >>>>>> to ANT.
> >>>>>>> Maven has a sass plugin to compile SASS.
> >>>>>>>
> >>>>>>> I saw you response and commented there
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> Carlos
> >>>>>>>
> >>>>>>>
> >>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
> >>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>>>>> escribió:
> >>>>>>>
> >>>>>>>> I replied on this topic on your commit email.
> >>>>>>>>
> >>>>>>>> So I don't have to copy that into this thread, read what I
> said in
> >>>>>> that
> >>>>>>>> email and reply on that thread and let's figure out the right
> thing
> >>>>>> to do.
> >>>>>>>> I am having some weird problem with my Maven build where
> every time
> >>>>>> I try
> >>>>>>>> to change Jewel's defaults.css something overwrites it. I'm
> trying
> >>>>>> to
> >>>>>>>> figure out what is going on there.
> >>>>>>>>
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <
> carlosrovira@apache.org <ma...@apache.org>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>> (<aharui@adobe.com.invalid <mailto:aharui@adobe.com.invalid
> >>)
> >>>>>>>> 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" <
> >>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
> >>>>>>>> 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
> >>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
> >>>>>>>>> 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" <
> >>>>>> carlosrovira@apache.org <ma...@apache.org>
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>> (<aharui@adobe.com.invalid <mailto:aharui@adobe.com.invalid
> >>)
> >>>>>>>>>> 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"
> >>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
> >>>>>>>>> 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" <
> >>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
> >>>>>>>>> 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
> >>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
> 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%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725599891&sdata=z5Qw0OvSwtILm%2B3e%2Bw9aKu02Hu4uLzIb540OehTuiro%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=ud9Eva2B84DoW%2B8d0xjB5cBX29PFyW8qKNvxihEoBNM%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%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725609846&sdata=sor6yeinm63kwuhkq8y0xWnNSlhC6E80lmT8wk5QRMU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> >>>
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=Kp9gcZ0f6ITkdFQAvOD2vWVACpJkgSuuNEYrYX884io%3D&reserved=0
> >>>
> >>>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Carlos Rovira
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725619797&sdata=CoGkfcg2u0cnM34NilDnAhNPLc71sHZw1mDXva5JNcU%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> >>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725629751&sdata=tQd7vkCt3B1QOiiu5XWXMzzUDSsKceMWDh1PegZKdgs%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> >>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725639714&sdata=9c1Ko4euWufPYt%2Bq0zhrzDezWY77%2FM92FO2LBDac6QE%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725649667&sdata=z4NUk9PMRcAxzHa6RY%2FYvfFUXIgt9xVL3RZyV9oRFjY%3D&reserved=0
> >>>
> >
> >
> >
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3e2d89dd1f54315e55708d7c48535c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637193948725649667&sdata=z4NUk9PMRcAxzHa6RY%2FYvfFUXIgt9xVL3RZyV9oRFjY%3D&reserved=0
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
in Jewel ComboBox something is not working as expected for ItemRenderers,
while in VirtualComboBox is working right. I mean rowCount/rowHeight.
If you check ComboBoxPlayGround in TDJ for an example where those
properties are set (the one with HSliders), you'll see those properties are
not causing effect. Instead in the VirtualPlayGround a similar
VirtualComboBox is configured with that properties and works ok.
I think the problem is in the mapper for List, that is different from
Basic. I can investigate if is a good time to remove jewel mappers now that
renderers are more modular, but I'll need a bit of documentation, since I'm
digging though all the code and is a bit cumbersome to imagine what's all
about.
So could you add some docs to the Itemrenderer royale doc page [1]? I think
it will be of help to me, and others here, and for users too.
Thanks in advance
Carlos
[1] https://apache.github.io/royale-docs/features/item-renderers
El lun., 2 mar. 2020 a las 9:28, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 3/1/20, 11:54 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Sure. I think separating Selection from the Renderer was the right
> thing to do, but we also need to figure out how to make it do the “right
> thing” be default.
>
> I’m wondering if there should be a “selectionBead” property in every
> item renderer which could be null.
>
> Maybe DataContainerBase should accept a selectionRenderer property the
> same way it accepts an itemRenderer?
>
>
> I don't know what your scenario really is, so don't have an opinion. The
> SelectableItemRendererClassFactory could look on the List's Strand for an
> instance of a bead that it can use instead of getting the class reference
> from CSS. It depends on where you want to control the configuration and
> why. I'm not sure there will be "one way".
>
> An item renderer should probably only have a selectionBead settable
> property if you can assign different selection beads per renderer, not per
> list, which is probably renderer-specific and not something for the base
> classes.
>
> FWIW, DataContainerBase isn't intended to support selection, it is just
> supposed to crank out a bunch of children for a container. The Lists are
> generally where selection becomes optional/required.
>
> -Alex
>
>
> > On Mar 2, 2020, at 9:47 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > More loosely-coupled pieces often results in head-scratching. But
> it also results in PAYG and flexibility.
> >
> > Our job is to find the common patterns, and pre-compose as needed,
> such as the Express component set. This "has" pattern is a new pattern so
> we'll have to figure out new best practices. And there are probably more
> than one. You might want to override what Selection bead is used
> >
> > 1) from some List-level config/attribute/css
> > 2) in the renderer itself
> > 3) by some renderer-level config/attribute/css
> >
> > IMO, it depends on where you want to control the composition.
> >
> > My 2 cents,
> > -Alex
> >
> > On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > Yes. If I replace the default SelectableItemRendererClassFactory
> >
> > My work-around was to use:
> >
> > js|List{
> > IItemRendererClassFactory:
> ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
> > }
> >
> > The average user will be scratching their heads on how to solve
> this problem.
> >
> >> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >>
> >>
> >> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>
> >> I’ve also discovered that setting the selection bead is more
> difficult than I would hope it to be.
> >>
> >> For example there should be an easy way to specify the selection
> bead in a situation like this:
> >>
> >> I may not be understanding the problem. The SpreadIconRenderer
> could have the SelectionBead in its bead list.
> >>
> >> -Alex
> >>
> >> <js:List
> >>
> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
> >> height="100%" width="100%"
> >> >
> >> <js:beads>
> >> <js:ArrayListSelectionModel/>
> >> <js:DataItemRendererFactoryForArrayList/>
> >> <js:EasyDataProviderChangeNotifier/>
> >> <js:VScrollViewport id="scrollView"/>
> >> </js:beads>
> >>
> >> </js:List>
> >>
> >>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>
> >>> I've tried two different patterns:
> >>>
> >>> 1) ItemRendererOwnerVIew via "has": See
> Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as.
> Then the ItemRendererClassFactory or the initializer can set it
> >>>
> >>> 2) Baking it in where needed and implementing
> IItemRendererOwnerView and setting it in the initializer.
> >>>
> >>> The main "benefit" of this part of the refactor is that not all
> item renderers need to be assigned a host since many don't need it, so it
> is PAYG for those who do. The advantage of the "has" approach is that
> custom item renderers don't add an itemRendererOwnerView property, but if
> the component doesn't allow custom item renderers, might be simpler to use
> approach #2.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>> What’s the recommended pattern for getting the “data host” from
> an itemRenderer now that itemRendererParent/itemRendererOwnerView is no
> longer a “thing”?
> >>>
> >>> I have the following code in an itemRenderer which inherits from
> DataItemRenderer:
> >>>
> >>> (itemRendererParent.host.parent as
> PagePalette).showMenuHandler(myValueEvent);
> >>>
> >>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>>
> >>>> It seemed like a separate concern. Right now there are two
> highly used ItemRendererClassFactory, but several Initializers.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>
> >>>> Why is IItemRendererInitializer separate from
> IItemRendererClassFactory?
> >>>>
> >>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui
> <ah...@adobe.com.invalid> wrote:
> >>>>>
> >>>>> I pushed changes that I think has everything working in Jewel by
> using the same "has" pattern that is used in other component sets.
> >>>>>
> >>>>> The Lists in the ToDo examples use a regular
> ItemRendererClassFactory instead of SelectableItemRendererClassFactory that
> is now used in most other places (List/DataGrid/Table)
> >>>>>
> >>>>> The recommended pattern for disabling selection in a list is
> whether you choose a ClassFactory that attaches a Selection Bead to each
> renderer. There was an exception to that rule in one of the Table examples
> because it wanted only certain renderers to not have selection. I added a
> bead that turns off the selection for that case. IMO, how to deal with
> such an exception will be based more on what percentage of the renderers
> need selection. If most do, then add a Selection Bead to all renderers but
> disable selection where you don't want it. If most do not want selection,
> then add the bead where you need it.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org
> <ma...@apache.org> <mailto:carlosrovira@apache.org <mailto:
> carlosrovira@apache.org>>> wrote:
> >>>>>
> >>>>> yes, Jewel has the "structure" and is organized in SASS files,
> then
> >>>>> JewelTheme has the "styling" part and is as well SASS.
> >>>>> so Jewel should not need to change, and people should only need
> to change
> >>>>> JewelTheme or create a new theme one using it as a template.
> >>>>>
> >>>>> I'll add examples to ant tomorrow
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>>
> >>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui
> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>>> escribió:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org
> <ma...@apache.org>> wrote:
> >>>>>>
> >>>>>> forgot to say. Can you add missing examples to ANT? don't know
> where
> >>>>>> to do
> >>>>>> that
> >>>>>> and checking Jewel don't see the use of
> >>>>>> SelectableItemRendererClassFactory.
> >>>>>> all times ItemRendererClassFactory is used
> >>>>>>
> >>>>>> I could fix the Ant side, but I don't have time. It think all
> you need to
> >>>>>> do is add it to the examples/build.xml
> >>>>>>
> >>>>>> I didn't use SelectableItemRendererClassFactory in Jewel
> because I wasn't
> >>>>>> sure if the selection was supposed to be changeable at
> runtime. I think
> >>>>>> you've confirmed that it isn't so we can change to use
> >>>>>> SelectableItemRendererClassFactory
> >>>>>>
> >>>>>> I knew the themes were generated by SASS, but I didn't realize
> the Jewel
> >>>>>> one was as well.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> >>>>>> carlosrovira@apache.org <ma...@apache.org>>)
> >>>>>> escribió:
> >>>>>>
> >>>>>>> Hi Alex,
> >>>>>>>
> >>>>>>> remember that Jewel uses SASS to create the CSS. I already
> pushed a
> >>>>>> commit
> >>>>>>> with ["warning"]. It's not the first time I warn about it ;)
> >>>>>>> You must to change SASS file. The css is just generated (like
> other
> >>>>>>> generations in compiler), and is committed since no body added
> SASS
> >>>>>> to ANT.
> >>>>>>> Maven has a sass plugin to compile SASS.
> >>>>>>>
> >>>>>>> I saw you response and commented there
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> Carlos
> >>>>>>>
> >>>>>>>
> >>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
> >>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>>>>> escribió:
> >>>>>>>
> >>>>>>>> I replied on this topic on your commit email.
> >>>>>>>>
> >>>>>>>> So I don't have to copy that into this thread, read what I
> said in
> >>>>>> that
> >>>>>>>> email and reply on that thread and let's figure out the right
> thing
> >>>>>> to do.
> >>>>>>>> I am having some weird problem with my Maven build where
> every time
> >>>>>> I try
> >>>>>>>> to change Jewel's defaults.css something overwrites it. I'm
> trying
> >>>>>> to
> >>>>>>>> figure out what is going on there.
> >>>>>>>>
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <
> carlosrovira@apache.org <ma...@apache.org>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>> (<aharui@adobe.com.invalid <mailto:aharui@adobe.com.invalid
> >>)
> >>>>>>>> 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" <
> >>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
> >>>>>>>> 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
> >>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
> >>>>>>>>> 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" <
> >>>>>> carlosrovira@apache.org <ma...@apache.org>
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>> (<aharui@adobe.com.invalid <mailto:aharui@adobe.com.invalid
> >>)
> >>>>>>>>>> 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"
> >>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
> >>>>>>>>> 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" <
> >>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
> >>>>>>>>> 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
> >>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
> 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%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%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%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0
> >>>
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=IPLVLQQP0NRQMMR5Dk4yBq2nEnIQsAANyDw%2BtUvoYkU%3D&reserved=0
> >>>
> >>>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Carlos Rovira
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0
> >>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0
> >>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>>
> >>>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> >>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0>>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0>
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0
> >>>
> >
> >
> >
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/1/20, 11:54 PM, "Harbs" <ha...@gmail.com> wrote:
Sure. I think separating Selection from the Renderer was the right thing to do, but we also need to figure out how to make it do the “right thing” be default.
I’m wondering if there should be a “selectionBead” property in every item renderer which could be null.
Maybe DataContainerBase should accept a selectionRenderer property the same way it accepts an itemRenderer?
I don't know what your scenario really is, so don't have an opinion. The SelectableItemRendererClassFactory could look on the List's Strand for an instance of a bead that it can use instead of getting the class reference from CSS. It depends on where you want to control the configuration and why. I'm not sure there will be "one way".
An item renderer should probably only have a selectionBead settable property if you can assign different selection beads per renderer, not per list, which is probably renderer-specific and not something for the base classes.
FWIW, DataContainerBase isn't intended to support selection, it is just supposed to crank out a bunch of children for a container. The Lists are generally where selection becomes optional/required.
-Alex
> On Mar 2, 2020, at 9:47 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> More loosely-coupled pieces often results in head-scratching. But it also results in PAYG and flexibility.
>
> Our job is to find the common patterns, and pre-compose as needed, such as the Express component set. This "has" pattern is a new pattern so we'll have to figure out new best practices. And there are probably more than one. You might want to override what Selection bead is used
>
> 1) from some List-level config/attribute/css
> 2) in the renderer itself
> 3) by some renderer-level config/attribute/css
>
> IMO, it depends on where you want to control the composition.
>
> My 2 cents,
> -Alex
>
> On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Yes. If I replace the default SelectableItemRendererClassFactory
>
> My work-around was to use:
>
> js|List{
> IItemRendererClassFactory: ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
> }
>
> The average user will be scratching their heads on how to solve this problem.
>
>> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>>
>>
>> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
>>
>> For example there should be an easy way to specify the selection bead in a situation like this:
>>
>> I may not be understanding the problem. The SpreadIconRenderer could have the SelectionBead in its bead list.
>>
>> -Alex
>>
>> <js:List
>> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
>> height="100%" width="100%"
>> >
>> <js:beads>
>> <js:ArrayListSelectionModel/>
>> <js:DataItemRendererFactoryForArrayList/>
>> <js:EasyDataProviderChangeNotifier/>
>> <js:VScrollViewport id="scrollView"/>
>> </js:beads>
>>
>> </js:List>
>>
>>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> I've tried two different patterns:
>>>
>>> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>>>
>>> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>>>
>>> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>>>
>>> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>>>
>>> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>>>
>>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>>>
>>>> -Alex
>>>>
>>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>>>
>>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>>>
>>>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>>>
>>>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>>>
>>>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>>>
>>>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>>>> JewelTheme has the "styling" part and is as well SASS.
>>>>> so Jewel should not need to change, and people should only need to change
>>>>> JewelTheme or create a new theme one using it as a template.
>>>>>
>>>>> I'll add examples to ant tomorrow
>>>>>
>>>>> thanks
>>>>>
>>>>>
>>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> escribió:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>>>
>>>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>>>> to do
>>>>>> that
>>>>>> and checking Jewel don't see the use of
>>>>>> SelectableItemRendererClassFactory.
>>>>>> all times ItemRendererClassFactory is used
>>>>>>
>>>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>>>> do is add it to the examples/build.xml
>>>>>>
>>>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>>>> you've confirmed that it isn't so we can change to use
>>>>>> SelectableItemRendererClassFactory
>>>>>>
>>>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>>>> one was as well.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>>>> escribió:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>>>> commit
>>>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>>>> You must to change SASS file. The css is just generated (like other
>>>>>>> generations in compiler), and is committed since no body added SASS
>>>>>> to ANT.
>>>>>>> Maven has a sass plugin to compile SASS.
>>>>>>>
>>>>>>> I saw you response and commented there
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Carlos
>>>>>>>
>>>>>>>
>>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> escribió:
>>>>>>>
>>>>>>>> I replied on this topic on your commit email.
>>>>>>>>
>>>>>>>> So I don't have to copy that into this thread, read what I said in
>>>>>> that
>>>>>>>> email and reply on that thread and let's figure out the right thing
>>>>>> to do.
>>>>>>>> I am having some weird problem with my Maven build where every time
>>>>>> I try
>>>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>>>> to
>>>>>>>> figure out what is going on there.
>>>>>>>>
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>> 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" <
>>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>>>> 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
>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>>>> 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" <
>>>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>>>> 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"
>>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>>>> 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" <
>>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>>>> 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
>>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438893605&sdata=OLsTF0QDnEscCtsFltzRttOMHMlalV12d%2FrdyeHU28o%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%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438903606&sdata=nKLTX5nI50Q3UTU4N6OluYcd46Wc7S%2F%2FmREW9LpO%2BAY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438913609&sdata=tcMmtzU%2BM839pkpZjJ%2BGpgxX0Y7ySB7QSGaggBGd3Ow%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=IPLVLQQP0NRQMMR5Dk4yBq2nEnIQsAANyDw%2BtUvoYkU%3D&reserved=0>>>
>>>>>>>>>> *
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>>
>>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438923602&sdata=z4JLx3m8XDiGpRmBsPLRbdM2owc2jr%2FwZJgT6isB%2B%2FA%3D&reserved=0>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438933591&sdata=EGe4%2Fsj3WGEePe3%2BI3aMi%2BAsryuAj3%2BbtKsFj%2BCKQQ4%3D&reserved=0>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438943582&sdata=KgUgf3To44Tx%2FiMHhZxndEcHy4UDq9M1eKB8fgZn3X8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C13f2511a60c84145eb7608d7be7edf15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187324438953577&sdata=fPeWXjO%2BAxcoBH4t04eHU46ONAm%2Bnz1lzZ71%2Fuux8Wc%3D&reserved=0>>>
>
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Harbs <ha...@gmail.com>.
Sure. I think separating Selection from the Renderer was the right thing to do, but we also need to figure out how to make it do the “right thing” be default.
I’m wondering if there should be a “selectionBead” property in every item renderer which could be null.
Maybe DataContainerBase should accept a selectionRenderer property the same way it accepts an itemRenderer?
> On Mar 2, 2020, at 9:47 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> More loosely-coupled pieces often results in head-scratching. But it also results in PAYG and flexibility.
>
> Our job is to find the common patterns, and pre-compose as needed, such as the Express component set. This "has" pattern is a new pattern so we'll have to figure out new best practices. And there are probably more than one. You might want to override what Selection bead is used
>
> 1) from some List-level config/attribute/css
> 2) in the renderer itself
> 3) by some renderer-level config/attribute/css
>
> IMO, it depends on where you want to control the composition.
>
> My 2 cents,
> -Alex
>
> On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Yes. If I replace the default SelectableItemRendererClassFactory
>
> My work-around was to use:
>
> js|List{
> IItemRendererClassFactory: ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
> }
>
> The average user will be scratching their heads on how to solve this problem.
>
>> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>>
>>
>> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
>>
>> For example there should be an easy way to specify the selection bead in a situation like this:
>>
>> I may not be understanding the problem. The SpreadIconRenderer could have the SelectionBead in its bead list.
>>
>> -Alex
>>
>> <js:List
>> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
>> height="100%" width="100%"
>> >
>> <js:beads>
>> <js:ArrayListSelectionModel/>
>> <js:DataItemRendererFactoryForArrayList/>
>> <js:EasyDataProviderChangeNotifier/>
>> <js:VScrollViewport id="scrollView"/>
>> </js:beads>
>>
>> </js:List>
>>
>>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> I've tried two different patterns:
>>>
>>> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>>>
>>> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>>>
>>> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>>>
>>> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>>>
>>> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>>>
>>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>>>
>>>> -Alex
>>>>
>>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>>>
>>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>>>
>>>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>>>
>>>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>>>
>>>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>>>
>>>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>>>> JewelTheme has the "styling" part and is as well SASS.
>>>>> so Jewel should not need to change, and people should only need to change
>>>>> JewelTheme or create a new theme one using it as a template.
>>>>>
>>>>> I'll add examples to ant tomorrow
>>>>>
>>>>> thanks
>>>>>
>>>>>
>>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> escribió:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>>>
>>>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>>>> to do
>>>>>> that
>>>>>> and checking Jewel don't see the use of
>>>>>> SelectableItemRendererClassFactory.
>>>>>> all times ItemRendererClassFactory is used
>>>>>>
>>>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>>>> do is add it to the examples/build.xml
>>>>>>
>>>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>>>> you've confirmed that it isn't so we can change to use
>>>>>> SelectableItemRendererClassFactory
>>>>>>
>>>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>>>> one was as well.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>>>> escribió:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>>>> commit
>>>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>>>> You must to change SASS file. The css is just generated (like other
>>>>>>> generations in compiler), and is committed since no body added SASS
>>>>>> to ANT.
>>>>>>> Maven has a sass plugin to compile SASS.
>>>>>>>
>>>>>>> I saw you response and commented there
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Carlos
>>>>>>>
>>>>>>>
>>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> escribió:
>>>>>>>
>>>>>>>> I replied on this topic on your commit email.
>>>>>>>>
>>>>>>>> So I don't have to copy that into this thread, read what I said in
>>>>>> that
>>>>>>>> email and reply on that thread and let's figure out the right thing
>>>>>> to do.
>>>>>>>> I am having some weird problem with my Maven build where every time
>>>>>> I try
>>>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>>>> to
>>>>>>>> figure out what is going on there.
>>>>>>>>
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>> 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" <
>>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>>>> 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
>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>>>> 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" <
>>>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>>>> 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"
>>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>>>> 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" <
>>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>>>> 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
>>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=RTMW7YySTvA3hD5EkQJauHXEgXEVWgnLIufpzhDmIcM%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=RTMW7YySTvA3hD5EkQJauHXEgXEVWgnLIufpzhDmIcM%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%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>>>
>>>>>>>>>> *
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>>
>>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0>>>
>
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
More loosely-coupled pieces often results in head-scratching. But it also results in PAYG and flexibility.
Our job is to find the common patterns, and pre-compose as needed, such as the Express component set. This "has" pattern is a new pattern so we'll have to figure out new best practices. And there are probably more than one. You might want to override what Selection bead is used
1) from some List-level config/attribute/css
2) in the renderer itself
3) by some renderer-level config/attribute/css
IMO, it depends on where you want to control the composition.
My 2 cents,
-Alex
On 3/1/20, 11:36 PM, "Harbs" <ha...@gmail.com> wrote:
Yes. If I replace the default SelectableItemRendererClassFactory
My work-around was to use:
js|List{
IItemRendererClassFactory: ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
}
The average user will be scratching their heads on how to solve this problem.
> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
>
> For example there should be an easy way to specify the selection bead in a situation like this:
>
> I may not be understanding the problem. The SpreadIconRenderer could have the SelectionBead in its bead list.
>
> -Alex
>
> <js:List
> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
> height="100%" width="100%"
> >
> <js:beads>
> <js:ArrayListSelectionModel/>
> <js:DataItemRendererFactoryForArrayList/>
> <js:EasyDataProviderChangeNotifier/>
> <js:VScrollViewport id="scrollView"/>
> </js:beads>
>
> </js:List>
>
>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I've tried two different patterns:
>>
>> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>>
>> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>>
>> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>>
>> HTH,
>> -Alex
>>
>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>>
>> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>>
>> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>>
>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>>
>>> -Alex
>>>
>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>>
>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>>
>>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>>
>>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>>
>>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>>
>>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>>> JewelTheme has the "styling" part and is as well SASS.
>>>> so Jewel should not need to change, and people should only need to change
>>>> JewelTheme or create a new theme one using it as a template.
>>>>
>>>> I'll add examples to ant tomorrow
>>>>
>>>> thanks
>>>>
>>>>
>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>> escribió:
>>>>
>>>>>
>>>>>
>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>>
>>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>>> to do
>>>>> that
>>>>> and checking Jewel don't see the use of
>>>>> SelectableItemRendererClassFactory.
>>>>> all times ItemRendererClassFactory is used
>>>>>
>>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>>> do is add it to the examples/build.xml
>>>>>
>>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>>> you've confirmed that it isn't so we can change to use
>>>>> SelectableItemRendererClassFactory
>>>>>
>>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>>> one was as well.
>>>>>
>>>>> -Alex
>>>>>
>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>>> escribió:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>>> commit
>>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>>> You must to change SASS file. The css is just generated (like other
>>>>>> generations in compiler), and is committed since no body added SASS
>>>>> to ANT.
>>>>>> Maven has a sass plugin to compile SASS.
>>>>>>
>>>>>> I saw you response and commented there
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Carlos
>>>>>>
>>>>>>
>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>> escribió:
>>>>>>
>>>>>>> I replied on this topic on your commit email.
>>>>>>>
>>>>>>> So I don't have to copy that into this thread, read what I said in
>>>>> that
>>>>>>> email and reply on that thread and let's figure out the right thing
>>>>> to do.
>>>>>>> I am having some weird problem with my Maven build where every time
>>>>> I try
>>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>>> to
>>>>>>> figure out what is going on there.
>>>>>>>
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> 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" <
>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>>> 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
>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>>> 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" <
>>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>>> 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"
>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>>> 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" <
>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>>> 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
>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004569381&sdata=IpOntughhCXPPt861IKfAXfZs%2BKmClbyQtjOU8lIsrU%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=RTMW7YySTvA3hD5EkQJauHXEgXEVWgnLIufpzhDmIcM%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=RTMW7YySTvA3hD5EkQJauHXEgXEVWgnLIufpzhDmIcM%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%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004579376&sdata=mpZDAOYuprs10WulFAtPJNMTV4khi9V%2BDnqZhZZmD1g%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>>>
>>>>>>>> <
>>>>>>>>
>>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004589368&sdata=QJMbdSYFy6%2B4NmCYGmYRpwNJf4ki9se0wMnfCxvLPFc%3D&reserved=0>>>
>>>>>>>>> *
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004599363&sdata=ef7NJBOfPnnpyD4TH3YX%2Bj6GPUoYEo1HzH1joXZZxkc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004609358&sdata=D2rkMzYRmzU6dCb5wQQse21TXtrivsDI7raAHFBo6qo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004619352&sdata=BNH%2FNyBDkTIJgl1p1laE7ATMaO7x76S9Y8rt5DwuA4A%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7f5ac54a36d14b4bef8e08d7be7c7183%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637187314004629356&sdata=28ldZ8kiXAIEMrT83C8Wa%2Ble6ElRKKVfJbUTDtfu%2FVc%3D&reserved=0>>>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Harbs <ha...@gmail.com>.
Yes. If I replace the default SelectableItemRendererClassFactory
My work-around was to use:
js|List{
IItemRendererClassFactory: ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
}
The average user will be scratching their heads on how to solve this problem.
> On Mar 2, 2020, at 1:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 3/1/20, 12:33 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
>
> For example there should be an easy way to specify the selection bead in a situation like this:
>
> I may not be understanding the problem. The SpreadIconRenderer could have the SelectionBead in its bead list.
>
> -Alex
>
> <js:List
> itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
> height="100%" width="100%"
> >
> <js:beads>
> <js:ArrayListSelectionModel/>
> <js:DataItemRendererFactoryForArrayList/>
> <js:EasyDataProviderChangeNotifier/>
> <js:VScrollViewport id="scrollView"/>
> </js:beads>
>
> </js:List>
>
>> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I've tried two different patterns:
>>
>> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>>
>> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>>
>> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>>
>> HTH,
>> -Alex
>>
>> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>>
>> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>>
>> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>>
>>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>>
>>> -Alex
>>>
>>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>>
>>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>>
>>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>>
>>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>>
>>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>>
>>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>>> JewelTheme has the "styling" part and is as well SASS.
>>>> so Jewel should not need to change, and people should only need to change
>>>> JewelTheme or create a new theme one using it as a template.
>>>>
>>>> I'll add examples to ant tomorrow
>>>>
>>>> thanks
>>>>
>>>>
>>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>> escribió:
>>>>
>>>>>
>>>>>
>>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>>
>>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>>> to do
>>>>> that
>>>>> and checking Jewel don't see the use of
>>>>> SelectableItemRendererClassFactory.
>>>>> all times ItemRendererClassFactory is used
>>>>>
>>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>>> do is add it to the examples/build.xml
>>>>>
>>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>>> you've confirmed that it isn't so we can change to use
>>>>> SelectableItemRendererClassFactory
>>>>>
>>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>>> one was as well.
>>>>>
>>>>> -Alex
>>>>>
>>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>>> escribió:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>>> commit
>>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>>> You must to change SASS file. The css is just generated (like other
>>>>>> generations in compiler), and is committed since no body added SASS
>>>>> to ANT.
>>>>>> Maven has a sass plugin to compile SASS.
>>>>>>
>>>>>> I saw you response and commented there
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Carlos
>>>>>>
>>>>>>
>>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>> escribió:
>>>>>>
>>>>>>> I replied on this topic on your commit email.
>>>>>>>
>>>>>>> So I don't have to copy that into this thread, read what I said in
>>>>> that
>>>>>>> email and reply on that thread and let's figure out the right thing
>>>>> to do.
>>>>>>> I am having some weird problem with my Maven build where every time
>>>>> I try
>>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>>> to
>>>>>>> figure out what is going on there.
>>>>>>>
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> 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" <
>>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>>> 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
>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>>> 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" <
>>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>>> 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"
>>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>>> 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" <
>>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>>> 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
>>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027427691&sdata=v5Wb1QyKL2tjIMFkVMvhw8V7145yxuvXWMZZrZUb9NA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027427691&sdata=v5Wb1QyKL2tjIMFkVMvhw8V7145yxuvXWMZZrZUb9NA%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%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%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0>>>
>>>>>>>> <
>>>>>>>>
>>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0>>>
>>>>>>>>> *
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>>>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/1/20, 12:33 AM, "Harbs" <ha...@gmail.com> wrote:
I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
For example there should be an easy way to specify the selection bead in a situation like this:
I may not be understanding the problem. The SpreadIconRenderer could have the SelectionBead in its bead list.
-Alex
<js:List
itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
height="100%" width="100%"
>
<js:beads>
<js:ArrayListSelectionModel/>
<js:DataItemRendererFactoryForArrayList/>
<js:EasyDataProviderChangeNotifier/>
<js:VScrollViewport id="scrollView"/>
</js:beads>
</js:List>
> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I've tried two different patterns:
>
> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>
> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>
> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>
> HTH,
> -Alex
>
> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>
> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>
> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>
>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>
>> -Alex
>>
>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>
>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>
>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>
>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>
>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>
>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>> JewelTheme has the "styling" part and is as well SASS.
>>> so Jewel should not need to change, and people should only need to change
>>> JewelTheme or create a new theme one using it as a template.
>>>
>>> I'll add examples to ant tomorrow
>>>
>>> thanks
>>>
>>>
>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>> escribió:
>>>
>>>>
>>>>
>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>> to do
>>>> that
>>>> and checking Jewel don't see the use of
>>>> SelectableItemRendererClassFactory.
>>>> all times ItemRendererClassFactory is used
>>>>
>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>> do is add it to the examples/build.xml
>>>>
>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>> you've confirmed that it isn't so we can change to use
>>>> SelectableItemRendererClassFactory
>>>>
>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>> one was as well.
>>>>
>>>> -Alex
>>>>
>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>> escribió:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>> commit
>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>> You must to change SASS file. The css is just generated (like other
>>>>> generations in compiler), and is committed since no body added SASS
>>>> to ANT.
>>>>> Maven has a sass plugin to compile SASS.
>>>>>
>>>>> I saw you response and commented there
>>>>>
>>>>> Thanks
>>>>>
>>>>> Carlos
>>>>>
>>>>>
>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> escribió:
>>>>>
>>>>>> I replied on this topic on your commit email.
>>>>>>
>>>>>> So I don't have to copy that into this thread, read what I said in
>>>> that
>>>>>> email and reply on that thread and let's figure out the right thing
>>>> to do.
>>>>>> I am having some weird problem with my Maven build where every time
>>>> I try
>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>> to
>>>>>> figure out what is going on there.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>> wrote:
>>>>>>
>>>>>> 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
>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>> 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" <
>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>> 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
>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>> 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" <
>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>
>>>>>>> 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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>> 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"
>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>> 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" <
>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>> 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
>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027427691&sdata=v5Wb1QyKL2tjIMFkVMvhw8V7145yxuvXWMZZrZUb9NA%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=ffsrLNYpouPk%2F2HjY6IX3GiCO6iYDM2I5ObzeQ9%2BDFI%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%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0>>
>>>>>>> <
>>>>>>>
>>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027437687&sdata=LaxIkzEekVbuxbOOqXsgVG9F0P2XOPwkdVV9KFPOCe0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=2hEsbLjF%2BrqQWYHgs0nFxTzVFA4vmRVctnud6DYeYAs%3D&reserved=0>>
>>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027447683&sdata=I%2F2%2FXmtnjyBQRzB02ZWp6FuXrpYtSFEk2rkmnol17OY%3D&reserved=0>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc727eef6521d443f1b9d08d7bdbb32a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186484027457674&sdata=mdbQToQsF167a%2BqiclnvkozTTbqQ1y2pjM%2BCM90xbKw%3D&reserved=0>>
>
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Harbs <ha...@gmail.com>.
I’ve also discovered that setting the selection bead is more difficult than I would hope it to be.
For example there should be an easy way to specify the selection bead in a situation like this:
<js:List
itemRenderer="com.printui.view.renderers.SpreadIconRenderer"
height="100%" width="100%"
>
<js:beads>
<js:ArrayListSelectionModel/>
<js:DataItemRendererFactoryForArrayList/>
<js:EasyDataProviderChangeNotifier/>
<js:VScrollViewport id="scrollView"/>
</js:beads>
</js:List>
> On Mar 1, 2020, at 1:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I've tried two different patterns:
>
> 1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
>
> 2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
>
> The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
>
> HTH,
> -Alex
>
> On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
>
> I have the following code in an itemRenderer which inherits from DataItemRenderer:
>
> (itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
>
>> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>>
>> -Alex
>>
>> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>>
>>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>>
>>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>>
>>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>>
>>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>
>>> yes, Jewel has the "structure" and is organized in SASS files, then
>>> JewelTheme has the "styling" part and is as well SASS.
>>> so Jewel should not need to change, and people should only need to change
>>> JewelTheme or create a new theme one using it as a template.
>>>
>>> I'll add examples to ant tomorrow
>>>
>>> thanks
>>>
>>>
>>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>> escribió:
>>>
>>>>
>>>>
>>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> forgot to say. Can you add missing examples to ANT? don't know where
>>>> to do
>>>> that
>>>> and checking Jewel don't see the use of
>>>> SelectableItemRendererClassFactory.
>>>> all times ItemRendererClassFactory is used
>>>>
>>>> I could fix the Ant side, but I don't have time. It think all you need to
>>>> do is add it to the examples/build.xml
>>>>
>>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>>> sure if the selection was supposed to be changeable at runtime. I think
>>>> you've confirmed that it isn't so we can change to use
>>>> SelectableItemRendererClassFactory
>>>>
>>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>>> one was as well.
>>>>
>>>> -Alex
>>>>
>>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>>> carlosrovira@apache.org <ma...@apache.org>>)
>>>> escribió:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>>> commit
>>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>>> You must to change SASS file. The css is just generated (like other
>>>>> generations in compiler), and is committed since no body added SASS
>>>> to ANT.
>>>>> Maven has a sass plugin to compile SASS.
>>>>>
>>>>> I saw you response and commented there
>>>>>
>>>>> Thanks
>>>>>
>>>>> Carlos
>>>>>
>>>>>
>>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> escribió:
>>>>>
>>>>>> I replied on this topic on your commit email.
>>>>>>
>>>>>> So I don't have to copy that into this thread, read what I said in
>>>> that
>>>>>> email and reply on that thread and let's figure out the right thing
>>>> to do.
>>>>>> I am having some weird problem with my Maven build where every time
>>>> I try
>>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>>> to
>>>>>> figure out what is going on there.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>>> wrote:
>>>>>>
>>>>>> 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
>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>> 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" <
>>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>> 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
>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>>> 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" <
>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>
>>>>>>> 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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>>> 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"
>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>> 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" <
>>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>>> 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
>>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%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%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0>>
>>>>>>> <
>>>>>>>
>>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0>>
>>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=f%2BBGrua%2F81gHW2MFaqLlsUz%2Fn42EM%2F3%2BRhcGBFgXpJQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=f%2BBGrua%2F81gHW2MFaqLlsUz%2Fn42EM%2F3%2BRhcGBFgXpJQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0>>
>
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I've tried two different patterns:
1) ItemRendererOwnerVIew via "has": See Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then the ItemRendererClassFactory or the initializer can set it
2) Baking it in where needed and implementing IItemRendererOwnerView and setting it in the initializer.
The main "benefit" of this part of the refactor is that not all item renderers need to be assigned a host since many don't need it, so it is PAYG for those who do. The advantage of the "has" approach is that custom item renderers don't add an itemRendererOwnerView property, but if the component doesn't allow custom item renderers, might be simpler to use approach #2.
HTH,
-Alex
On 2/29/20, 12:17 PM, "Harbs" <ha...@gmail.com> wrote:
What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
I have the following code in an itemRenderer which inherits from DataItemRenderer:
(itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>
> -Alex
>
> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>
>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>
>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>
>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>
>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>
>> Thanks,
>> -Alex
>>
>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>
>> yes, Jewel has the "structure" and is organized in SASS files, then
>> JewelTheme has the "styling" part and is as well SASS.
>> so Jewel should not need to change, and people should only need to change
>> JewelTheme or create a new theme one using it as a template.
>>
>> I'll add examples to ant tomorrow
>>
>> thanks
>>
>>
>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>> escribió:
>>
>>>
>>>
>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>
>>> forgot to say. Can you add missing examples to ANT? don't know where
>>> to do
>>> that
>>> and checking Jewel don't see the use of
>>> SelectableItemRendererClassFactory.
>>> all times ItemRendererClassFactory is used
>>>
>>> I could fix the Ant side, but I don't have time. It think all you need to
>>> do is add it to the examples/build.xml
>>>
>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>> sure if the selection was supposed to be changeable at runtime. I think
>>> you've confirmed that it isn't so we can change to use
>>> SelectableItemRendererClassFactory
>>>
>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>> one was as well.
>>>
>>> -Alex
>>>
>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>> carlosrovira@apache.org <ma...@apache.org>>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>> commit
>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>> You must to change SASS file. The css is just generated (like other
>>>> generations in compiler), and is committed since no body added SASS
>>> to ANT.
>>>> Maven has a sass plugin to compile SASS.
>>>>
>>>> I saw you response and commented there
>>>>
>>>> Thanks
>>>>
>>>> Carlos
>>>>
>>>>
>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>> escribió:
>>>>
>>>>> I replied on this topic on your commit email.
>>>>>
>>>>> So I don't have to copy that into this thread, read what I said in
>>> that
>>>>> email and reply on that thread and let's figure out the right thing
>>> to do.
>>>>> I am having some weird problem with my Maven build where every time
>>> I try
>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>> to
>>>>> figure out what is going on there.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>> wrote:
>>>>>
>>>>> 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
>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> 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" <
>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>> 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
>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>> 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" <
>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>
>>>>>> 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
>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> 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"
>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>> 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" <
>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>> 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
>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393878510&sdata=s6LoyOChzCW2lO2xU8JEqiD%2FCVHYUV9sZyOoLysTtvQ%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%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0>>
>>>>>> <
>>>>>>
>>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393883500&sdata=35JeUKrOS81xVlNvUWl87CY05SzNRG%2ByLuIpGViYgzs%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=JvrwYpbAXvqnaoUluil0Uh3fUhTmj8CBQP1XmIbpimI%3D&reserved=0>>
>>>>>>> *
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=f%2BBGrua%2F81gHW2MFaqLlsUz%2Fn42EM%2F3%2BRhcGBFgXpJQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393888493&sdata=f%2BBGrua%2F81gHW2MFaqLlsUz%2Fn42EM%2F3%2BRhcGBFgXpJQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393893485&sdata=GJc5ixZRWC8gbmrQWIotOSgWuPG%2FFIrGg9AJYdqlwaw%3D&reserved=0>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393898473&sdata=bytSd%2FzJCnIcHuuQ5g%2B%2B7n3HhB8qvPxDViMVvQ9RbKg%3D&reserved=0>>
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0caae0445e594bd93f9d08d7bd545f73%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637186042393903463&sdata=L6qd9XN05eLsRvO6Q6pdMKhBFE6swax9KtqPUeUb7XE%3D&reserved=0>>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Harbs <ha...@gmail.com>.
What’s the recommended pattern for getting the “data host” from an itemRenderer now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
I have the following code in an itemRenderer which inherits from DataItemRenderer:
(itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);
> On Feb 24, 2020, at 7:02 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
>
> -Alex
>
> On 2/24/20, 3:06 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> Why is IItemRendererInitializer separate from IItemRendererClassFactory?
>
>> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>>
>> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>>
>> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>>
>> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>>
>> Thanks,
>> -Alex
>>
>> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>
>> yes, Jewel has the "structure" and is organized in SASS files, then
>> JewelTheme has the "styling" part and is as well SASS.
>> so Jewel should not need to change, and people should only need to change
>> JewelTheme or create a new theme one using it as a template.
>>
>> I'll add examples to ant tomorrow
>>
>> thanks
>>
>>
>> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>> escribió:
>>
>>>
>>>
>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>
>>> forgot to say. Can you add missing examples to ANT? don't know where
>>> to do
>>> that
>>> and checking Jewel don't see the use of
>>> SelectableItemRendererClassFactory.
>>> all times ItemRendererClassFactory is used
>>>
>>> I could fix the Ant side, but I don't have time. It think all you need to
>>> do is add it to the examples/build.xml
>>>
>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>> sure if the selection was supposed to be changeable at runtime. I think
>>> you've confirmed that it isn't so we can change to use
>>> SelectableItemRendererClassFactory
>>>
>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>> one was as well.
>>>
>>> -Alex
>>>
>>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>> carlosrovira@apache.org <ma...@apache.org>>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>> commit
>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>> You must to change SASS file. The css is just generated (like other
>>>> generations in compiler), and is committed since no body added SASS
>>> to ANT.
>>>> Maven has a sass plugin to compile SASS.
>>>>
>>>> I saw you response and commented there
>>>>
>>>> Thanks
>>>>
>>>> Carlos
>>>>
>>>>
>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>> escribió:
>>>>
>>>>> I replied on this topic on your commit email.
>>>>>
>>>>> So I don't have to copy that into this thread, read what I said in
>>> that
>>>>> email and reply on that thread and let's figure out the right thing
>>> to do.
>>>>> I am having some weird problem with my Maven build where every time
>>> I try
>>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>>> to
>>>>> figure out what is going on there.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>>
>>> wrote:
>>>>>
>>>>> 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
>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>> 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" <
>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>> 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
>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>>>>> 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" <
>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>
>>>>>> 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
>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>>>>> 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"
>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>> 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" <
>>>>> greg.dove@gmail.com <ma...@gmail.com>>
>>>>>> 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
>>>>>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>> 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%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%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%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0>>
>>>>>> <
>>>>>>
>>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=xR9hDvBawl6sQwSD95C27PGQD6pwIj9qZ4BRXwKgjYU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=xR9hDvBawl6sQwSD95C27PGQD6pwIj9qZ4BRXwKgjYU%3D&reserved=0>>
>>>>>>> *
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>>
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It seemed like a separate concern. Right now there are two highly used ItemRendererClassFactory, but several Initializers.
-Alex
On 2/24/20, 3:06 AM, "Harbs" <ha...@gmail.com> wrote:
Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>
> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>
> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>
> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>
> Thanks,
> -Alex
>
> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>
> yes, Jewel has the "structure" and is organized in SASS files, then
> JewelTheme has the "styling" part and is as well SASS.
> so Jewel should not need to change, and people should only need to change
> JewelTheme or create a new theme one using it as a template.
>
> I'll add examples to ant tomorrow
>
> thanks
>
>
> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>>
>>
>> On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> forgot to say. Can you add missing examples to ANT? don't know where
>> to do
>> that
>> and checking Jewel don't see the use of
>> SelectableItemRendererClassFactory.
>> all times ItemRendererClassFactory is used
>>
>> I could fix the Ant side, but I don't have time. It think all you need to
>> do is add it to the examples/build.xml
>>
>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>> sure if the selection was supposed to be changeable at runtime. I think
>> you've confirmed that it isn't so we can change to use
>> SelectableItemRendererClassFactory
>>
>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>> one was as well.
>>
>> -Alex
>>
>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>> carlosrovira@apache.org>)
>> escribió:
>>
>>> Hi Alex,
>>>
>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>> commit
>>> with ["warning"]. It's not the first time I warn about it ;)
>>> You must to change SASS file. The css is just generated (like other
>>> generations in compiler), and is committed since no body added SASS
>> to ANT.
>>> Maven has a sass plugin to compile SASS.
>>>
>>> I saw you response and commented there
>>>
>>> Thanks
>>>
>>> Carlos
>>>
>>>
>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>> (<ah...@adobe.com.invalid>)
>>> escribió:
>>>
>>>> I replied on this topic on your commit email.
>>>>
>>>> So I don't have to copy that into this thread, read what I said in
>> that
>>>> email and reply on that thread and let's figure out the right thing
>> to do.
>>>> I am having some weird problem with my Maven build where every time
>> I try
>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>> to
>>>> figure out what is going on there.
>>>>
>>>> -Alex
>>>>
>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>>>>
>>>> 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
>>>> (<ah...@adobe.com.invalid>)
>>>> 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" <
>> piotrzarzycki21@gmail.com>
>>>> 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
>> <ah...@adobe.com.invalid>
>>>>> 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" <
>> carlosrovira@apache.org
>>>>>
>>>>> 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
>>>>>> (<ah...@adobe.com.invalid>)
>>>>>> 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"
>>>> <ah...@adobe.com.INVALID>
>>>>> 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" <
>>>> greg.dove@gmail.com>
>>>>> 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
>>>>>>> <ah...@adobe.com.invalid> 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%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%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%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0>
>>>>> <
>>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=xR9hDvBawl6sQwSD95C27PGQD6pwIj9qZ4BRXwKgjYU%3D&reserved=0>
>>>>>> *
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>
>>
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&reserved=0>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Harbs <ha...@gmail.com>.
Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> On Feb 21, 2020, at 12:03 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
>
> I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
>
> The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
>
> The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
>
> Thanks,
> -Alex
>
> On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>
> yes, Jewel has the "structure" and is organized in SASS files, then
> JewelTheme has the "styling" part and is as well SASS.
> so Jewel should not need to change, and people should only need to change
> JewelTheme or create a new theme one using it as a template.
>
> I'll add examples to ant tomorrow
>
> thanks
>
>
> El jue., 20 feb. 2020 a las 20:17, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>>
>>
>> On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> forgot to say. Can you add missing examples to ANT? don't know where
>> to do
>> that
>> and checking Jewel don't see the use of
>> SelectableItemRendererClassFactory.
>> all times ItemRendererClassFactory is used
>>
>> I could fix the Ant side, but I don't have time. It think all you need to
>> do is add it to the examples/build.xml
>>
>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>> sure if the selection was supposed to be changeable at runtime. I think
>> you've confirmed that it isn't so we can change to use
>> SelectableItemRendererClassFactory
>>
>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>> one was as well.
>>
>> -Alex
>>
>> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>> carlosrovira@apache.org>)
>> escribió:
>>
>>> Hi Alex,
>>>
>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>> commit
>>> with ["warning"]. It's not the first time I warn about it ;)
>>> You must to change SASS file. The css is just generated (like other
>>> generations in compiler), and is committed since no body added SASS
>> to ANT.
>>> Maven has a sass plugin to compile SASS.
>>>
>>> I saw you response and commented there
>>>
>>> Thanks
>>>
>>> Carlos
>>>
>>>
>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>> (<ah...@adobe.com.invalid>)
>>> escribió:
>>>
>>>> I replied on this topic on your commit email.
>>>>
>>>> So I don't have to copy that into this thread, read what I said in
>> that
>>>> email and reply on that thread and let's figure out the right thing
>> to do.
>>>> I am having some weird problem with my Maven build where every time
>> I try
>>>> to change Jewel's defaults.css something overwrites it. I'm trying
>> to
>>>> figure out what is going on there.
>>>>
>>>> -Alex
>>>>
>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>>>>
>>>> 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
>>>> (<ah...@adobe.com.invalid>)
>>>> 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" <
>> piotrzarzycki21@gmail.com>
>>>> 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
>> <ah...@adobe.com.invalid>
>>>>> 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" <
>> carlosrovira@apache.org
>>>>>
>>>>> 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
>>>>>> (<ah...@adobe.com.invalid>)
>>>>>> 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"
>>>> <ah...@adobe.com.INVALID>
>>>>> 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" <
>>>> greg.dove@gmail.com>
>>>>> 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
>>>>>>> <ah...@adobe.com.invalid> 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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0>
>>>>> <
>>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0>
>>>>>> *
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0>
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0>
>>
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets.
The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/DataGrid/Table)
The recommended pattern for disabling selection in a list is whether you choose a ClassFactory that attaches a Selection Bead to each renderer. There was an exception to that rule in one of the Table examples because it wanted only certain renderers to not have selection. I added a bead that turns off the selection for that case. IMO, how to deal with such an exception will be based more on what percentage of the renderers need selection. If most do, then add a Selection Bead to all renderers but disable selection where you don't want it. If most do not want selection, then add the bead where you need it.
Thanks,
-Alex
On 2/20/20, 11:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
yes, Jewel has the "structure" and is organized in SASS files, then
JewelTheme has the "styling" part and is as well SASS.
so Jewel should not need to change, and people should only need to change
JewelTheme or create a new theme one using it as a template.
I'll add examples to ant tomorrow
thanks
El jue., 20 feb. 2020 a las 20:17, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> forgot to say. Can you add missing examples to ANT? don't know where
> to do
> that
> and checking Jewel don't see the use of
> SelectableItemRendererClassFactory.
> all times ItemRendererClassFactory is used
>
> I could fix the Ant side, but I don't have time. It think all you need to
> do is add it to the examples/build.xml
>
> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
> sure if the selection was supposed to be changeable at runtime. I think
> you've confirmed that it isn't so we can change to use
> SelectableItemRendererClassFactory
>
> I knew the themes were generated by SASS, but I didn't realize the Jewel
> one was as well.
>
> -Alex
>
> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > remember that Jewel uses SASS to create the CSS. I already pushed a
> commit
> > with ["warning"]. It's not the first time I warn about it ;)
> > You must to change SASS file. The css is just generated (like other
> > generations in compiler), and is committed since no body added SASS
> to ANT.
> > Maven has a sass plugin to compile SASS.
> >
> > I saw you response and commented there
> >
> > Thanks
> >
> > Carlos
> >
> >
> > El jue., 20 feb. 2020 a las 19:55, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> I replied on this topic on your commit email.
> >>
> >> So I don't have to copy that into this thread, read what I said in
> that
> >> email and reply on that thread and let's figure out the right thing
> to do.
> >> I am having some weird problem with my Maven build where every time
> I try
> >> to change Jewel's defaults.css something overwrites it. I'm trying
> to
> >> figure out what is going on there.
> >>
> >> -Alex
> >>
> >> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> 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
> >> (<ah...@adobe.com.invalid>)
> >> 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" <
> piotrzarzycki21@gmail.com>
> >> 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
> <ah...@adobe.com.invalid>
> >> > 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" <
> carlosrovira@apache.org
> >> >
> >> > 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
> >> > > (<ah...@adobe.com.invalid>)
> >> > > 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"
> >> <ah...@adobe.com.INVALID>
> >> > 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" <
> >> greg.dove@gmail.com>
> >> > 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
> >> > > > <ah...@adobe.com.invalid> 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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%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%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
> >> > <
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
> >> > >*
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
yes, Jewel has the "structure" and is organized in SASS files, then
JewelTheme has the "styling" part and is as well SASS.
so Jewel should not need to change, and people should only need to change
JewelTheme or create a new theme one using it as a template.
I'll add examples to ant tomorrow
thanks
El jue., 20 feb. 2020 a las 20:17, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> forgot to say. Can you add missing examples to ANT? don't know where
> to do
> that
> and checking Jewel don't see the use of
> SelectableItemRendererClassFactory.
> all times ItemRendererClassFactory is used
>
> I could fix the Ant side, but I don't have time. It think all you need to
> do is add it to the examples/build.xml
>
> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
> sure if the selection was supposed to be changeable at runtime. I think
> you've confirmed that it isn't so we can change to use
> SelectableItemRendererClassFactory
>
> I knew the themes were generated by SASS, but I didn't realize the Jewel
> one was as well.
>
> -Alex
>
> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > remember that Jewel uses SASS to create the CSS. I already pushed a
> commit
> > with ["warning"]. It's not the first time I warn about it ;)
> > You must to change SASS file. The css is just generated (like other
> > generations in compiler), and is committed since no body added SASS
> to ANT.
> > Maven has a sass plugin to compile SASS.
> >
> > I saw you response and commented there
> >
> > Thanks
> >
> > Carlos
> >
> >
> > El jue., 20 feb. 2020 a las 19:55, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> I replied on this topic on your commit email.
> >>
> >> So I don't have to copy that into this thread, read what I said in
> that
> >> email and reply on that thread and let's figure out the right thing
> to do.
> >> I am having some weird problem with my Maven build where every time
> I try
> >> to change Jewel's defaults.css something overwrites it. I'm trying
> to
> >> figure out what is going on there.
> >>
> >> -Alex
> >>
> >> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> 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
> >> (<ah...@adobe.com.invalid>)
> >> 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" <
> piotrzarzycki21@gmail.com>
> >> 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
> <ah...@adobe.com.invalid>
> >> > 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" <
> carlosrovira@apache.org
> >> >
> >> > 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
> >> > > (<ah...@adobe.com.invalid>)
> >> > > 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"
> >> <ah...@adobe.com.INVALID>
> >> > 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" <
> >> greg.dove@gmail.com>
> >> > 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
> >> > > > <ah...@adobe.com.invalid> 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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
> >> > <
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
> >> > >*
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 2/20/20, 11:04 AM, "Carlos Rovira" <ca...@apache.org> wrote:
forgot to say. Can you add missing examples to ANT? don't know where to do
that
and checking Jewel don't see the use of SelectableItemRendererClassFactory.
all times ItemRendererClassFactory is used
I could fix the Ant side, but I don't have time. It think all you need to do is add it to the examples/build.xml
I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't sure if the selection was supposed to be changeable at runtime. I think you've confirmed that it isn't so we can change to use SelectableItemRendererClassFactory
I knew the themes were generated by SASS, but I didn't realize the Jewel one was as well.
-Alex
El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> remember that Jewel uses SASS to create the CSS. I already pushed a commit
> with ["warning"]. It's not the first time I warn about it ;)
> You must to change SASS file. The css is just generated (like other
> generations in compiler), and is committed since no body added SASS to ANT.
> Maven has a sass plugin to compile SASS.
>
> I saw you response and commented there
>
> Thanks
>
> Carlos
>
>
> El jue., 20 feb. 2020 a las 19:55, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> I replied on this topic on your commit email.
>>
>> So I don't have to copy that into this thread, read what I said in that
>> email and reply on that thread and let's figure out the right thing to do.
>> I am having some weird problem with my Maven build where every time I try
>> to change Jewel's defaults.css something overwrites it. I'm trying to
>> figure out what is going on there.
>>
>> -Alex
>>
>> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> 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
>> (<ah...@adobe.com.invalid>)
>> 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" <pi...@gmail.com>
>> 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 <ah...@adobe.com.invalid>
>> > 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" <carlosrovira@apache.org
>> >
>> > 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
>> > > (<ah...@adobe.com.invalid>)
>> > > 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"
>> <ah...@adobe.com.INVALID>
>> > 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" <
>> greg.dove@gmail.com>
>> > 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
>> > > > <ah...@adobe.com.invalid> 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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
>> > <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
>> > >*
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
forgot to say. Can you add missing examples to ANT? don't know where to do
that
and checking Jewel don't see the use of SelectableItemRendererClassFactory.
all times ItemRendererClassFactory is used
El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> remember that Jewel uses SASS to create the CSS. I already pushed a commit
> with ["warning"]. It's not the first time I warn about it ;)
> You must to change SASS file. The css is just generated (like other
> generations in compiler), and is committed since no body added SASS to ANT.
> Maven has a sass plugin to compile SASS.
>
> I saw you response and commented there
>
> Thanks
>
> Carlos
>
>
> El jue., 20 feb. 2020 a las 19:55, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> I replied on this topic on your commit email.
>>
>> So I don't have to copy that into this thread, read what I said in that
>> email and reply on that thread and let's figure out the right thing to do.
>> I am having some weird problem with my Maven build where every time I try
>> to change Jewel's defaults.css something overwrites it. I'm trying to
>> figure out what is going on there.
>>
>> -Alex
>>
>> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> 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
>> (<ah...@adobe.com.invalid>)
>> 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" <pi...@gmail.com>
>> 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 <ah...@adobe.com.invalid>
>> > 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" <carlosrovira@apache.org
>> >
>> > 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
>> > > (<ah...@adobe.com.invalid>)
>> > > 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"
>> <ah...@adobe.com.INVALID>
>> > 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" <
>> greg.dove@gmail.com>
>> > 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
>> > > > <ah...@adobe.com.invalid> 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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
>> > <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
>> > >*
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
remember that Jewel uses SASS to create the CSS. I already pushed a commit
with ["warning"]. It's not the first time I warn about it ;)
You must to change SASS file. The css is just generated (like other
generations in compiler), and is committed since no body added SASS to ANT.
Maven has a sass plugin to compile SASS.
I saw you response and commented there
Thanks
Carlos
El jue., 20 feb. 2020 a las 19:55, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I replied on this topic on your commit email.
>
> So I don't have to copy that into this thread, read what I said in that
> email and reply on that thread and let's figure out the right thing to do.
> I am having some weird problem with my Maven build where every time I try
> to change Jewel's defaults.css something overwrites it. I'm trying to
> figure out what is going on there.
>
> -Alex
>
> On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> 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
> (<ah...@adobe.com.invalid>)
> 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" <pi...@gmail.com>
> 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 <ah...@adobe.com.invalid>
> > 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" <ca...@apache.org>
> > 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
> > > (<ah...@adobe.com.invalid>)
> > > 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"
> <ah...@adobe.com.INVALID>
> > 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" <
> greg.dove@gmail.com>
> > 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
> > > > <ah...@adobe.com.invalid> 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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
> > >*
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I replied on this topic on your commit email.
So I don't have to copy that into this thread, read what I said in that email and reply on that thread and let's figure out the right thing to do. I am having some weird problem with my Maven build where every time I try to change Jewel's defaults.css something overwrites it. I'm trying to figure out what is going on there.
-Alex
On 2/20/20, 10:47 AM, "Carlos Rovira" <ca...@apache.org> wrote:
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 (<ah...@adobe.com.invalid>)
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" <pi...@gmail.com> 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 <ah...@adobe.com.invalid>
> 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" <ca...@apache.org>
> 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
> > (<ah...@adobe.com.invalid>)
> > 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" <ah...@adobe.com.INVALID>
> 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" <gr...@gmail.com>
> 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
> > > <ah...@adobe.com.invalid> 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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%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%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0
> >*
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%3D&reserved=0
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@adobe.com.invalid>)
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" <pi...@gmail.com> 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 <ah...@adobe.com.invalid>
> 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" <ca...@apache.org>
> 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
> > (<ah...@adobe.com.invalid>)
> > 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" <ah...@adobe.com.INVALID>
> 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" <gr...@gmail.com>
> 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
> > > <ah...@adobe.com.invalid> 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
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <pi...@gmail.com> 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 <ah...@adobe.com.invalid> 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" <ca...@apache.org> 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
> (<ah...@adobe.com.invalid>)
> 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" <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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
> > <ah...@adobe.com.invalid> 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>*
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@adobe.com.invalid> 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" <ca...@apache.org> 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
> (<ah...@adobe.com.invalid>)
> 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" <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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
> > <ah...@adobe.com.invalid> 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%7Ca0b67274fc9846fefc3908d7b40a1c97%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637175827836116014&sdata=c%2BDlyWnFJpTFErPaMw%2F5NM9NWf2hlPfpPSO%2FfoLvo04%3D&reserved=0
>
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@apache.org> 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 (<ah...@adobe.com.invalid>)
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" <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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
> <ah...@adobe.com.invalid> 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%7Ca0b67274fc9846fefc3908d7b40a1c97%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637175827836116014&sdata=c%2BDlyWnFJpTFErPaMw%2F5NM9NWf2hlPfpPSO%2FfoLvo04%3D&reserved=0
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@adobe.com.invalid>)
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" <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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
> <ah...@adobe.com.invalid> 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
http://about.me/carlosrovira
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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 <ah...@adobe.com.invalid> 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
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@gmail.com> 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 <ah...@adobe.com.invalid> 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
>
>
Re: "has" vs "is": sharing code, swapping out subsystems, and more...
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@adobe.com.invalid> 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
>
>