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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636486039218 >879495&sdata=PmoDkP7b2qvJ%2Fq%2Btkoht2i1buQXEp%2FjSR%2Ftc9OXMUno%3D&reserv >ed=0>*
