royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com.INVALID>
Subject Re: [Royale - ASJS] PAYG list beads
Date Fri, 01 Dec 2017 14:59:41 GMT
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
up.

Again, thanks for pointing this out.
‹peter

On 11/30/17, 7:33 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

>Hi,
>
>>  thinking that when you add DataProviderItemsChangeNotifier to a List
>>strand, you could also replace the itemRenderer factory that is more
>>"capable":
>> 
>> 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).
>
>Thanks,
>Justin
>
>1. 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourcemak
>ing.com%2Fdesign_patterns%2Fdecorator&data=02%7C01%7Cpent%40adobe.com%7C94
>dc46d35417405d838d08d5385323db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>7C636476852095520303&sdata=VBGHJoNyY1%2BK5T8ZtpWlNmYJGKatuqzkCt4TO%2F1%2By
>XI%3D&reserved=0


Mime
View raw message