royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <>
Subject Re: [Royale - ASJS] PAYG list beads
Date Fri, 01 Dec 2017 16:23:41 GMT
Update (aka, Thinking Out Loud):

I think the way to go here is to have new beads like ItemsAdded,
ItemsRemoved, ItemsChanged, added to DataItemRendererFactoryForArrayList
and that bead can delegate the updating of the DataGroup to those beads,
if present. The default can be a bead that listens for
"dataProviderChanged" and do the wholesale replace that the factory bead
does now.

The factory beads will need to have a change in their interfaces to
support having their own beads and to be able to delegate to them.


On 12/1/17, 9:59 AM, "Peter Ent" <> wrote:

>Thanks for the reminder, Justin.
>I had thought about the Decorator pattern; after all, beads really should
>be thought of as Decorators. When we add a password protection bead to the
>TextInput component, it does not change what the TextInput component is,
>it merely enhances it.
>The problem is that some things in Royale have wandered away from the
>Decorator pattern. The DataItemRendererFactory* beads probably do too
>much. For example, not only are they listening for a "dataProviderChanged"
>event, they act on it by erasing the current itemRenderers and generating
>new ones. 
>To me, a Decorator version of the DataItemRendererFactory would simply
>provide an itemRenderer from information passed to it (such as the class
>to use). Responding to items being added, changed, or removed would not
>fall to the factory but to something else that would call upon the factory
>to create a new itemRenderer if needed.
>The question becomes, what part of a List (or DataContainer) is
>responsible for driving the creation of itemRenderers and listening for
>other changes? To make that a replaceable part, the DataContainer needs a
>core engine that can delegate to its Decorators the responsibility of
>modifying the visuals (itemRenderers) in various ways. That is, in one
>case the addition of a datum to the model would cause a wholesale
>replacement of all itemRenderers and in another case a single new
>itemRenderer would be inserted into the display list.
>In either case, the layout beads would then need to know something has
>changed (we do have an event for that) to process the children. Some
>layouts would need to examine every child and move and/or resize it.
>Another layout might cause a fluid effect of sliding some items down to
>insert the new item - which means the item being inserted has to be
>communicated to the layout in a PAYG fashion (meaning: many layouts won't
>need this information but a few might).
>The PAYG world gives us lots of opportunities to craft this in different
>ways. I will re-think this now that the Decorator pattern has been brought
>Again, thanks for pointing this out.
>On 11/30/17, 7:33 PM, "Justin Mclean" <> wrote:
>>>  thinking that when you add DataProviderItemsChangeNotifier to a List
>>>strand, you could also replace the itemRenderer factory that is more
>>> DataItemRendererFactoryForArrayListSupportsItemsAdded
>>> DataItemRendererFactoryForArrayListSupportsItemsRemoved
>>> DataItemRendererFactoryForArrayListSupportsItemsAddedAndRemoved
>>> DataItemRendererFactoryForArrayListSupportsItemsChanged
>>> DataItemRendererFactoryForArrayListSupportsItemsAddedChangedAndRemoved
>>A suggestion would be looking into using the decorator design pattern [1]
>>that way you would only need three beads (and less code duplication).

View raw message