royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <>
Subject Re: [royale-asjs] 02/02: Revert "Updating the source of an ArrayList does not change the view of the component without this change."
Date Tue, 31 Oct 2017 19:25:02 GMT

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

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.


On 10/30/17, 11:27 AM, "Yishay Weiss" <> 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 <>
>Sent: Sunday, October 29, 2017 1:48:19 AM
>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, wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>> harbs pushed a commit to branch develop
>> in repository 
>> commit 9d20a649a7d417ca62724c98f3906c0d160172ae
>> Author: Harbs <>
>> 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/
>> | 1 +
>> 1 file changed, 1 insertion(+)
>> diff --git 
>> index ec10892..81c606c 100644
>> --- 
>> +++ 
>> @@ -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 >=
>> --
>> To stop receiving notification emails like this one, please contact
>> "" <>.

View raw message