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" <[email protected]> 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%7C3e768dcacec447640aa208d54007a62b%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0 >%7C636485323953316454&sdata=sRTfb3ro%2Fj66%2FHhWWEU6ZgOsNo9jqlqtEdE7nNF9Py >A%3D&reserved=0
