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