Hi, I've been going over this and sketching stuff in my notebook. I'd like to do a little reset thinking about DataGrid.
First, the idea of moving updates to the dataProvider from the DataGridView into a separate beads seem like a good idea to me. It should allow how that gets handled to be changed if needed without affecting how the DataGrid is composed. The DataGrid is composed of a ButtonBar and a Container which has a set of Lists, one per column. The idea is that the Lists share the dataProvider found in the DataGridModel and from this dataProvider, along with the DataGridColumn specifications (also in the DataGridModel), generate itemRenderer instances. I don't know if this is the best way to make a DataGrid in Royale; it seems like it but it is also a little difficult getting the Lists to coordinate with each other. Forgot - for the moment - about PAYG. Ideally, the dataProvider is capable of sending out events when it changes - new items added, items changed, items deleted. Since the Lists are using the same dataProvider, the Lists should be able to react to those changes and update themselves accordingly. This means something in the Lists - probably their models - is set up to listen for changes to the dataProvider and then get whatever is in the Lists to handle the dataProvider[index] <-> itemRenderer mapping. If you delete dataProvider[2] (the third item), the dataProvider would send an ITEM_DELETED event out. The Lists have a bead that is generating the itemRenderers from the dataProvider and it does so when the dataProvider changes. Those mapper beads should pick up the delete event and remove the corresponding itemRenderer. Then those beads send out a LAYOUT_NEEDED event. The layout beads for each List then take the itemRenderers and arrange them according to their algorithms. (Note that LAYOUT_NEEDED is dispatched from the List itself as a common listening point for intra-bead communication). This, at least, is how it should work. Bringing back PAYG: Not everyone needs dataProviders that can handle dynamic changes. Which is why the List has beads for both Array based dataProviders and ArrayList dataProviders. There are also Array and ArrayList data provider/itemRenderer mappers. When dealing with Array, the common case, I think model and mapper beads should only respond to wholesale changes to the dataProvider - effectively replacement. Array doesn't produce change events, so the basic beads should not handle them. In PAYG fashion, the ArrayList model and mapper beads should handle dynamic changes. Maybe at first the mapper bead would just treat everything the same: delete all itemRenderers and re-generate them and then dispatch LAYOUT_NEEDED. Updated versions could handle change, insert, and delete with better event messages from the mapper to the layout which means another set of fancy layout beads that handle subtle changes and fit with the PAYG philosophy. I hope that helps. Its how I view things. I do believe the ArrayList version of the models and mappers need updating a bit, especially now that we've learned more in putting this system together. ‹peter On 10/30/17, 11:27 AM, "Yishay Weiss" <[email protected]> wrote: >Currently the composite view (DataGridView) has some code designed to >propagate the data change event to its subviews (DataGridColumnList). I >think we need to move this code to a separate bead. Then we¹ll have finer >control over whether or not changes in runtime are reflected in the view. >I¹ll try to create a branch demonstrating this. > > > >________________________________ >From: Harbs <[email protected]> >Sent: Sunday, October 29, 2017 1:48:19 AM >To: [email protected] >Subject: Re: [royale-asjs] 02/02: Revert "Updating the source of an >ArrayList does not change the view of the component without this change." > >This change made updating the dataProvider in the DataGridExample work, >but it seems to have caused an endless recursive layout in some cases. > >I¹ve reverted it because it seems to have broken existing apps, but I¹m >not completely sure why. > >I¹m left with the question of how to allow changes to ArrayLists >propagating to the view without causing the endless loopŠ > >> On Oct 29, 2017, at 1:43 AM, [email protected] wrote: >> >> This is an automated email from the ASF dual-hosted git repository. >> >> harbs pushed a commit to branch develop >> in repository >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.a >>pache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7C%7C48422f6c72824 >>d28c34608d51faad3da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63644974 >>0915040368&sdata=s0gVEd8QkdUsNoIjAQOSmkO6tWR5ka0WhpAONQkfIIc%3D&reserved= >>0 >> >> commit 9d20a649a7d417ca62724c98f3906c0d160172ae >> Author: Harbs <[email protected]> >> AuthorDate: Sun Oct 29 01:41:08 2017 +0200 >> >> Revert "Updating the source of an ArrayList does not change the view >>of the component without this change." >> >> This reverts commit 313cf14147dfdd53b621b82b949b8544d2b6ed91. >> --- >> .../org/apache/royale/html/beads/models/ArrayListSelectionModel.as >> | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git >>a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ >>models/ArrayListSelectionModel.as >>b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ >>models/ArrayListSelectionModel.as >> index ec10892..81c606c 100644 >> --- >>a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ >>models/ArrayListSelectionModel.as >> +++ >>b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ >>models/ArrayListSelectionModel.as >> @@ -84,6 +84,7 @@ package org.apache.royale.html.beads.models >> */ >> public function set dataProvider(value:Object):void >> { >> + if (value == _dataProvider) return; >> >> _dataProvider = value as IArrayList; >> if(!_dataProvider || _selectedIndex >= >>_dataProvider.length) >> >> -- >> To stop receiving notification emails like this one, please contact >> "[email protected]" <[email protected]>. >
