royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: [Royale - ASJS] PAYG list beads
Date Sun, 03 Dec 2017 19:49:05 GMT
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 <yishayjobs@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 <pent@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" <pent@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" <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%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>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message