You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Peter Ent <pe...@adobe.com.INVALID> on 2017/11/30 22:33:27 UTC
[Royale - ASJS] PAYG list beads
Hi,
I'm developing a TreeGrid (Tree/DataGrid hybrid). It could use the ability to add and remove rows on the fly. Right now, we only can add/remove/change data to our dataProvider and then have all of the itemRenderers re-generated. At least I do not see that there exists beads to do otherwise.
I'm 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
This would keep with the PAYG philosophy and let developers choose the precise features they wanted to include.
What do you think? Does something like this already exist and I just don't see it; I don't want to duplicate effort.
—peter
Re: [Royale - ASJS] PAYG list beads
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Peter,
I'm working on small project and it look like I will need some of your
beads in MDL. I'm not sure whether you are aware but there is already bead
which is doing adding. You could rename it if that code is ok.
DynamicItemsRendererFactoryForArrayListData -> MDLDynamicTableExample
I will need also from your list
DataItemRendererFactoryForArrayListSupportsItemsRemoved
and one additional where we are handling "CollectionEvent.ITEM_UPDATED" (
DataItemRendererFactoryForArrayListSupportsItemsChanged - This bead will do
handle ITEM_UPDATED ? )
I would like to ask what is your progress on that task ? Are you going to
commit soon at least those beads ?
Thanks, Piotr
2017-12-03 8:24 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> I may be missing something but it looks to me like we already have this
> separation.
>
>
>
> IItemRendererClassFactory is responsible for the item renderers, and
> IDataProviderItemRendererMapper listens to change events and
> inserts/removes the item renderer instances.
>
>
>
> ________________________________
> From: Peter Ent <pe...@adobe.com.INVALID>
> Sent: Friday, December 1, 2017 6:23:41 PM
> To: dev@royale.apache.org
> Subject: Re: [Royale - ASJS] PAYG list beads
>
> 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.
>
> —peter
>
>
>
> On 12/1/17, 9:59 AM, "Peter Ent" <pe...@adobe.com.INVALID> 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
> >up.
> >
> >Again, thanks for pointing this out.
> >‹peter
> >
> >On 11/30/17, 7:33 PM, "Justin Mclean" <ju...@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%2Fsourcema
> >>k
> >>ing.com%2Fdesign_patterns%2Fdecorator&data=02%7C01%7Cpent%40adobe.com
> %7C9
> >>4
> >>dc46d35417405d838d08d5385323db%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0
> >>%
> >>7C636476852095520303&sdata=VBGHJoNyY1%2BK5T8ZtpWlNmYJGKatuqzkCt4TO%
> 2F1%2B
> >>y
> >>XI%3D&reserved=0
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
RE: [Royale - ASJS] PAYG list beads
Posted by Yishay Weiss <yi...@hotmail.com>.
I may be missing something but it looks to me like we already have this separation.
IItemRendererClassFactory is responsible for the item renderers, and IDataProviderItemRendererMapper listens to change events and inserts/removes the item renderer instances.
________________________________
From: Peter Ent <pe...@adobe.com.INVALID>
Sent: Friday, December 1, 2017 6:23:41 PM
To: dev@royale.apache.org
Subject: Re: [Royale - ASJS] PAYG list beads
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.
—peter
On 12/1/17, 9:59 AM, "Peter Ent" <pe...@adobe.com.INVALID> 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
>up.
>
>Again, thanks for pointing this out.
>‹peter
>
>On 11/30/17, 7:33 PM, "Justin Mclean" <ju...@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%2Fsourcema
>>k
>>ing.com%2Fdesign_patterns%2Fdecorator&data=02%7C01%7Cpent%40adobe.com%7C9
>>4
>>dc46d35417405d838d08d5385323db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0
>>%
>>7C636476852095520303&sdata=VBGHJoNyY1%2BK5T8ZtpWlNmYJGKatuqzkCt4TO%2F1%2B
>>y
>>XI%3D&reserved=0
>
Re: [Royale - ASJS] PAYG list beads
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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.
—peter
On 12/1/17, 9:59 AM, "Peter Ent" <pe...@adobe.com.INVALID> 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
>up.
>
>Again, thanks for pointing this out.
>‹peter
>
>On 11/30/17, 7:33 PM, "Justin Mclean" <ju...@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%2Fsourcema
>>k
>>ing.com%2Fdesign_patterns%2Fdecorator&data=02%7C01%7Cpent%40adobe.com%7C9
>>4
>>dc46d35417405d838d08d5385323db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0
>>%
>>7C636476852095520303&sdata=VBGHJoNyY1%2BK5T8ZtpWlNmYJGKatuqzkCt4TO%2F1%2B
>>y
>>XI%3D&reserved=0
>
Re: [Royale - ASJS] PAYG list beads
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <ju...@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
Re: [Royale - ASJS] PAYG list beads
Posted by Justin Mclean <ju...@classsoftware.com>.
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://sourcemaking.com/design_patterns/decorator