royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: [Royale] Collection work
Date Tue, 02 Jan 2018 20:58:21 GMT
How are you doing that preservation, by simply saving item somewhere before
remove/add operation ?

I'm not following the part where we you wanted some opinion. Actually in
case of refreshing I didn't even thing about saving selection, but it's
true that it should happen! It's surprises me that in my app I forgot about
that. :)

Thanks, Piotr


2018-01-02 21:44 GMT+01:00 Peter Ent <pent@adobe.com.invalid>:

> The first task is to determine if a list's selectedIndex or selectedItem
> should be preserved.
>
> For selectedIndex, adding or removing an item will get the same row
> selected until that row no longer exists.
>
> For selectedItem, adding or removing an item will keep the same item
> selected until that item no longer exists. For example, if the 4th item is
> "red" and you insert an item at position 2, "red" remains selected by
> shifts down a row.
>
> I can see this working both ways.
>
> In either case, first preserving the selection (index or item) before the
> add or remove and then restoring it works fine - I did this in application
> code, not in framework code. Works very nicely, as a matter of fact. Works
> for both traditional lists and dynamic lists with the new beads (yours,
> Piotr, or my new collection ones). Its *very simple* code.
>
> So once we decide which selection is preserved, we need to decide where
> that goes. Even though this code is just a couple of lines, in the PAYG
> world, not every app needs this so it must go into additional beads since
> it is added functionality.
>
> —peter
>
>
>
>
>
> On 1/2/18, 1:31 PM, "Piotr Zarzycki" <piotrzarzycki21@gmail.com> wrote:
>
> >Hi Peter,
> >
> >Welcome after vacation! I sense all ideas when I'm working with that
> >stuff.
> >I think you will see the issue with indexes, even if it's not the case
> >with
> >removing from the list. I will wait for your review with that index
> >refresh.
> >
> >Thank you so much! :)
> >
> >
> >2018-01-02 19:10 GMT+01:00 Peter Ent <pent@adobe.com.invalid>:
> >
> >> Hi,
> >>
> >> Catching up and building stuff. I'm going to repeat some things for the
> >> befit of anyone joining Royale for 2018 (and to refresh my own thoughts
> >> coming off of holiday!).
> >>
> >> The initial idea of List and related classes was their beads were to be
> >> almost static. You'd have data that you would use to create the
> >> dataProvider to the list and when set, would cause the itemRenderers to
> >>be
> >> deleted and replaced. Even something as simple as adding new data to the
> >> end of the dataProvider would require this reset: you'd have to clear
> >>the
> >> dataProvider (list.dataProver = null) and set it again or create a
> >> completely new dataProvider and set that to the list.
> >>
> >> The selected item and index should, in this case, be cleared. I'd have
> >>to
> >> run a test to see if that really happens as I don't remember. If you
> >>want
> >> to reset them back (assuming that index still existed) you would write a
> >> bead to do it.
> >>
> >> Now we are at the dynamic stage where we want to handle runtime updates
> >>to
> >> the dataProvider and create just new itemRenderers and insert them or
> >> remove itemRenderers when data is deleted from the dataProvider.
> >>
> >> Alex believes that the initial creation and insertions are the most
> >>common
> >> of the dynamic actions; removals being less common. As such in the PAYG
> >> world you would have a bead that handled a replacement of the
> >>dataProvider
> >> (which covers the initialization step) and a bead which handled
> >>additions
> >> and a bead to handle removals. There's a lot of duplication of code in
> >> these and under a non-PAYG system you'd just combine these into a single
> >> bead to do initialize, add, and removal.
> >>
> >> In the dynamic beads, the selection should be preserved. That
> >>information
> >> is stored in the model. The model doesn't do much else accept keep the
> >> data. The standard view bead would not know about these extra events so
> >> yes, we'd need another view bead to intercept those events and re-apply
> >>or
> >> adjust the selection.
> >>
> >> ‹peter
> >>
> >> On 12/30/17, 4:29 PM, "Piotr Zarzycki" <piotrzarzycki21@gmail.com>
> >>wrote:
> >>
> >> >Peter,
> >> >
> >> >I have figure out what is wrong in case of List. I reported in the
> >> >previous
> >> >email that in the ListExample once you remove one item, something is
> >>wrong
> >> >with selection. Issue happened when you removing item in the middle of
> >> >collection.
> >> >
> >> >Let's say that you have 5 items and you are removing item with index =
> >>2.
> >> >Removing will work properly, but StringItemRenderer ->
> >> >DataItemRenderer -> UIItemRendererBase
> >> ><- has property "index" which is basically not being refreshed after
> >> >remove. In the result renderers has following indexes:
> >> >
> >> >0,
> >> >1,
> >> >3,
> >> >4
> >> >
> >> >Which is messes up selection and roll over color changes. How actually
> >>fix
> >> >that ? My first thought was that ListView should listen for
> >>"layoutNeeded"
> >> >(we are dispatching that event after remove, add etc.) and refresh
> >>indexes
> >> >of all renderers.
> >> >
> >> >The second thought is that ListView should listen for remove event,
> >>where
> >> >we will have index of removed row, so we will be able loop through
> >>part of
> >> >the collection and refresh rest of the indexes. It is more efficient,
> >>but
> >> >maybe this is job for new type of View (bead) - ListRemoveView bead ?
> >> >
> >> >Looking forward to your thought once you get back from Vacation. :)
> >> >
> >> >Thanks, Piotr
> >> >
> >> >
> >> >
> >> >2017-12-22 15:05 GMT+01:00 Piotr Zarzycki <piotrzarzycki21@gmail.com>:
> >> >
> >> >> Hi Peter,
> >> >>
> >> >> I haven't checked your branch yet, but I just pushed couple of
> >>things to
> >> >> the develop which I needed for my examples. Here is the list of beads
> >> >>which
> >> >> we currently have and can be used for List. I think names are self
> >> >> explanatory.
> >> >>
> >> >> DynamicAddItemRendererForArrayListData
> >> >>
> >> >> DynamicUpdateItemRendererForArrayListData
> >> >>
> >> >> DynamicRemoveItemRendererForArrayListData
> >> >>
> >> >> DynamicRemoveAllItemRendererForArrayListData
> >> >>
> >> >> DynamicRemoveAllByNullItemRendererForArrayListData
> >> >>
> >> >> All beads above should be used once you set for your list:
> >> >>IDataProviderItemRendererMapper:
> >> >>ClassReference("org.apache.royale.html.beads.
> >> DataItemRendererFactoryForAr
> >> >>rayList")
> >> >>
> >> >> We have also DynamicItemsRendererFactoryForArrayListData - which is
> >> >>doing actually two things. Create all items once someone set
> >> >>dataProvider (the same logic as in
> >>DataItemRendererFactoryForArrayList)
> >> >>AND handle adding to
> >> >>
> >> >> ArrayList (the same logic as in
> >>DynamicAddItemRendererForArrayListData)
> >> >>- It duplicates logic from those both beads.
> >> >>
> >> >>
> >> >> Two Scenarios with DynamicItemsRendererFactoryForArrayListData:
> >> >>
> >> >> 1) If we use DynamicItemsRendererFactoryForArrayListData simply in
> >>the
> >> >>List as it is in our ListExample [1] we don't have to remember to
> >>setup:
> >> >>
> >> >> IDataProviderItemRendererMapper:
> >> >>ClassReference("org.apache.royale.html.beads.
> >> DataItemRendererFactoryForAr
> >> >>rayList").
> >> >>
> >> >> However in that scenario we will have in List totally useless bead
> >> >>DataItemRendererFactoryForArray which is being added default to the
> >> List.
> >> >>
> >> >> 2) If we use DynamicItemsRendererFactoryForArrayListData and we add
> >>in
> >> >>CSS  IDataProviderItemRendererMapper:
> >> >>ClassReference("org.apache.royale.html.beads.
> >> DataItemRendererFactoryForAr
> >> >>rayList")
> >> >>
> >> >> I'm not sure what can happen actually, cause both beads are using the
> >> >>same logic to create item renderers. Can be situation when one bead
is
> >> >>create renderers and second one re do this work again ? :)
> >> >>
> >> >>
> >> >> Thanks, Piotr
> >> >>
> >> >>
> >> >>
> >> >> [1]
> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fgithub.c
> >> >>om%2Fapache%2Froyale-asjs%2Fblob%2F24b09c787fc1da2d0a19895a2b2d
> >> 4a440e26c5
> >> >>97%2Fexamples%2Froyale%2FListExample%2Fsrc%2Fmain%
> >> 2Froyale%2FMyInitialVie
> >> >>w.mxml%23L69&data=02%7C01%7Cpent%40adobe.com%
> >> 7C94d879f8f6054e10c75508d54f
> >> >>cc6fe8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636502661827506659&sd
> >> >>ata=W4Ih5Q0IGhGNvOX9jrmn580Qw4ljo%2BavjqABV4%2BJr%2Bc%3D&reserved=0
> >> >>
> >> >>
> >> >>
> >> >> 2017-12-19 20:35 GMT+01:00 Olaf Krueger <mail@olafkrueger.net>:
> >> >>
> >> >>> Peter, great to read something about these "Collections" and
> >> >>>"Hierarchical
> >> >>> data" stuff here!
> >> >>> Thanks for working on this, have a nice time and enjoy your break!
> >> >>>
> >> >>> Olaf
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Sent from:
> >> >>>https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fapache-r
> >> >>>oyale-development.20373.n8.nabble.com%2F&data=02%7C01%7Cpent%
> >> 40adobe.com
> >> >>>%7C94d879f8f6054e10c75508d54fcc6fe8%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7
> >> >>>C0%7C0%7C636502661827506659&sdata=Zb1nVaD5dUx1Y89Q1jj4LxqBhtlxoZ
> >> FlwDFJAq
> >> >>>ruTsY%3D&reserved=0
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Piotr Zarzycki
> >> >>
> >> >> Patreon:
> >> >>*https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fwww.pat
> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com
> >> %7C94d879f8f6054e
> >> >>10c75508d54fcc6fe8%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636502661
> >> >>827506659&sdata=sjS%2Fmydo1M%2FGkkREJsc5CRyA1uFXRUK76zEHFeg
> >> FXtA%3D&reserv
> >> >>ed=0
> >> >>
> >> >><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fwww.pat
> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com
> >> %7C94d879f8f6054e
> >> >>10c75508d54fcc6fe8%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636502661
> >> >>827506659&sdata=sjS%2Fmydo1M%2FGkkREJsc5CRyA1uFXRUK76zEHFeg
> >> FXtA%3D&reserv
> >> >>ed=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%
> >> 7C94d879f8f6054e10
> >> >c75508d54fcc6fe8%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636502661827
> >> >506659&sdata=sjS%2Fmydo1M%2FGkkREJsc5CRyA1uFXRUK76zEHFeg
> >> FXtA%3D&reserved=0
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fwww.patr
> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com%
> >> 7C94d879f8f6054e10
> >> >c75508d54fcc6fe8%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636502661827
> >> >506659&sdata=sjS%2Fmydo1M%2FGkkREJsc5CRyA1uFXRUK76zEHFeg
> >> FXtA%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%
> 7C96bb80bb6fef4b94
> >089008d5520f1a9f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636505147194
> >474371&sdata=D3%2FGi2wtNJLEO716RK18TbD1VMFdB3VKv3Br5KkZfFI%3D&reserved=0
> ><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Cpent%40adobe.com%
> 7C96bb80bb6fef4b94
> >089008d5520f1a9f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636505147194
> >474371&sdata=D3%2FGi2wtNJLEO716RK18TbD1VMFdB3V
> Kv3Br5KkZfFI%3D&reserved=0>*
>
>


-- 

Piotr Zarzycki

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message