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" <[email protected]> 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
