Peter,

I will try your changes soon. I was thinking what you did write earlier and
maybe I wasn't enough clear. I'm talking right now about following cases.
Let's say that you have list or MDL Table doesn't matter and you did
specify in your css file following class:

.myList
{
     IDataProviderItemRendererMapper: ClassReference(
"org.apache.royale.html.beads.DataItemRendererFactoryForArrayList");
}

and in your MXML:

<js:List className="myList">
<js:beads>
<js:DynamicItemsRendererFactoryForArrayListData />
</js:beads>
</js:List>

It means that apart of the code which is handling adding to us in
DynamicItemsRendererFactoryForArrayListData - we have right now in both
beads duplicated code, which is doing exactly the same. - I'm not sure what
can happen if we have both beads added.

However I do understand also other use cases.

Thanks, Piotr


2017-12-11 17:16 GMT+01:00 Peter Ent <p...@adobe.com.invalid>:

> I committed the change to the remove bead after running the MDLExample
> with no errors in the browser console.
>
> Hope this works!
> —peter
>
> On 12/11/17, 10:45 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:
>
> >Hi Peter,
> >
> >If I remember correctly I was using those beads [1] and as
> >IDataProviderItemRendererMapper:
> >DynamicItemsRendererFactoryForArrayListData
> >- declared in CSS. You can take a look into the example
> >MDLDynamicTableExample.
> >
> >With your solution where we are looking actually into the events from
> >dataProvider, I just thought that code which creates item renderers is not
> >needed in DynamicItemsRendererFactoryForArrayListData.
> >
> >Looking forward to the results of your investigation.
> >
> >[1]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2F07m8&data=02%7C01%7Cpent%40adobe.com%
> 7C835b99b029af47936d8508d54
> >0ae2eda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636486039218879495&sd
> >ata=cghdpJo101E1sgl%2FgG2VFahFno78Y8nwfiks7bbPdHE%3D&reserved=0
> >
> >Thanks, Piotr
> >
> >
> >2017-12-11 16:29 GMT+01:00 Peter Ent <p...@adobe.com.invalid>:
> >
> >> In the PAYG world of Royale, we need to keep a number of features
> >>separate
> >> so apps are not weighed down by unused code. I originally had a bead
> >>that
> >> refreshed all item renderers by deleting them from the DataGroup and
> >> re-creating them. I also had a bead that just created itemRenderers on
> >> demand when it detected an ItemAdded event. Likewise, a bead to remove
> >> them on demand. To avoid duplicating code, I had the refresh bead look
> >>for
> >> the add bead and use it (there was a public function to create an
> >> itemRenderer). This kept things very separate. However, the refresh bead
> >> required the add bead so Alex suggested combining the two since there
> >>was
> >> really nothing being gained by the separation. Removal is considered an
> >> "extra" since many apps do not need to remove things. I don't know if
> >> that's really true, but it fits the PAYG model.
> >>
> >> The ArrayList itself emits events. It is also a dataProvider that can be
> >> used with a model. I find this to be confusing sometimes, but that's
> >>just
> >> me.
> >>
> >> Piotr, I don't see how your original version of
> >> DynamicItemsRendererFactoryForArrayListData could have worked since the
> >> model does not dispatch ItemAdded events; only ArrayList (the model's
> >> dataProvider) does that. In my tests, the DynamicŠData bead never
> >>received
> >> the event until I changed it.
> >>
> >> Personally, I think the collection classes should emit their own events,
> >> but when used within a model, the model should intercept them and
> >> re-dispatch the events as their own. This would make writing beads
> >>cleaner
> >> and we would not need as many variations that only differ by how the
> >> dataProvider is accessed as all access to the dataProvider would go
> >> through the model via a standard interface.
> >>
> >> I will figure out why the removal bead is failing and then re-test with
> >> MDL but I won't change anything else unless there is no other choice.
> >>
> >> ‹peter
> >>
> >> On 12/10/17, 2:53 PM, "piotrz" <pio...@apache.org> wrote:
> >>
> >> >Hi Peter,
> >> >
> >> >Ok DynamicItemsRendererFactoryForArrayListData is now working
> >>perfectly.
> >> >Unfortunately I just tried DynamicRemoveItemRendererForArrayListData
> >>and
> >> >got
> >> >NPE. This time dataProviderModel is being null
> >> >
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fapache-ro
> >> >yale-development.20373.n8.nabble.com%2Ffile%2Ft1%
> >> 2Fdynamic_remove_null.png
> >> >&data=02%7C01%7Cpent%40adobe.com%7C3e768dcacec447640aa208d54007
> >> a62b%7Cfa7b
> >> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636485323953316454&
> >> sdata=iktsZuL5sc
> >> >DNbJu26jprPRlwA3Zx0w%2FJVriETkMQLqo%3D&reserved=0>
> >> >
> >> >There is in general something wrong and I think there a bit more work.
> >> >DynamicItemsRendererFactoryForArrayListData  now is different than
> >> >DynamicRemoveItemRendererForArrayListData, cause the first on have
> >>logic
> >> >which is not only adding item renderer, but also creates them which is
> >>not
> >> >present in the Remove version.
> >> >
> >> >In the other words DynamicItemsRendererFactoryForArrayListData it is
> >> >IDataProviderItemRendererMapper. I think we should go with following
> >> >changes.
> >> >
> >> >1) DynamicItemsRendererFactoryForArrayListData  - logic for creating
> >>item
> >> >renderers should be removed from that bead
> >> >2) We should rename DynamicItemsRendererFactoryForArrayListData  to
> >> >DynamicAddItemRendererForArrayListData
> >> >3) For List, MDL Table, MDL Tabs and all things inherited from List
> >>should
> >> >as IDataProviderItemRendererMapper we should use:
> >> >DataItemRendererFactoryForArrayData or
> >> >DataItemRendererFactoryForSeriesArrayListData (use this to have all
> the
> >> >advantages of above beads).
> >> >
> >> >What do you think ?
> >> >
> >> >If you will make above changes check all the MDL examples which have
> >>Tabs,
> >> >Tables etc. - Build MDLExample.
> >> >
> >> >Thanks, Piotr
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >--
> >> >Sent from:
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fapache-roy
> >> >ale-development.20373.n8.nabble.com%2F&data=02%7C01%7Cpent%40adobe.com
> >> %7C3
> >> >e768dcacec447640aa208d54007a62b%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0
> >>
> >>>%7C636485323953316454&sdata=sRTfb3ro%2Fj66%
> 2FHhWWEU6ZgOsNo9jqlqtEdE7nNF9
> >>>P
> >> y
> >> >A%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >
> >Piotr Zarzycki
> >
> >Patreon:
> >*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com%
> 7C835b99b029af4793
> >6d8508d540ae2eda%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636486039218
> >879495&sdata=PmoDkP7b2qvJ%2Fq%2Btkoht2i1buQXEp%2FjSR%
> 2Ftc9OXMUno%3D&reserv
> >ed=0
> ><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com%
> 7C835b99b029af4793
> >6d8508d540ae2eda%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636486039218
> >879495&sdata=PmoDkP7b2qvJ%2Fq%2Btkoht2i1buQXEp%2FjSR%
> 2Ftc9OXMUno%3D&reserv
> >ed=0>*
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Reply via email to