Thanks for the quick reply Alex. I am keen to get the mx DataGrid support
in as soon as possible.
So at the moment I am inclined to go with the single commit approach which
we both agree provides a simple revert option if it was ever needed.
But I will wait one day to see if others have different views.


On Thu, Apr 30, 2020 at 12:03 PM Alex Harui <[email protected]>
wrote:

> Alina is out on parenting leave.  Pashmina is driving the effort on that
> project.  She had a deadline for 4/30 so it would be risky to make big
> changes to ADG right now.  On the other hand if it is all in one commit
> they can revert the commit.
>
> I'm not sure they are working every day where they live.  There were no
> emails from Pashmina today, IIRC.  So if you can wait 72 hours before
> committing might be safer, but like I said, Pashmina can revert the commit
> and use a local build.
>
> -Alex
>
> On 4/29/20, 4:42 PM, "Greg Dove" <[email protected]> wrote:
>
>     I checked with Alex recently on status for mx DataGrid and understood
> it
>     needed work. I need mx DataGrid for a low level dependency in some
> client
>     work, so I have worked on that.
>     I know mx ADG is in a working state, so my goal was to get mx DataGrid
> into
>     a similar state that allows for initial use, and for subsequent
> improvement.
>
>     In doing so I have also addressed a couple of bugs I saw in ADG:
>     1. clicking on the sort headers caused selection behaviour in list area
>     2.sortable="false" was not being respected from DataGridColumns (did
> not
>     disable sort for that header button)
>
>     I need a definitive preference/answer for whether it is ok for me to
> push
>     my changes to develop or if current ADG users want these to go to a
> branch
>     for now. This could be from Alina (or Alex on her behalf) or anyone
> else
>     who is currently using mx ADG. More information follows... if I hear
>     nothing by this time tomorrow I will assume a single commit to develop
> with
>     the changes will be ok (see explanation below, about how this minimises
>     potential risk to others)
>
>     Details:
>     I don't know how many others are using ADG (I know Alina is for sure).
> As
>     part of the work on mx DataGrid I did refactor some things from ADG
> down to
>     lower level classes, leveraging as much as I could of what Alex had
> already
>     done, to permit shared use of lower level code in some cases between
> the
>     two DataGrid classes. Mostly this mirrored the original Flex code, but
>     in some cases it was more Royale-like for the 'under-the-hood' support
> in
>     things like layout, for example.
>     So I want to check how I should migrate these changes into develop
> because
>     I have made some changes to ADG itself. If others currently using ADG
>     prefer, I can add it to a branch for now, but I do need commitment
> that you
>     will check that branch so I can merge into develop in a short
> timeframe.
>     Or, more practically I think, I can make this as a single commit into
>     develop that is easily reverted if there are any issues that arise in
> ADG
>     as a result (I don't expect any - it should be fine, but I don't want
> to
>     cause problems if there is anything that does arise from this change -
> if
>     anything *that currently works* in ADG stops working after this
> change, I
>     will address it)
>
>     Other things:
>     For mx DataGrid I used non-virtualized list layout for now. I could see
>     some issues in ADG with fast mouse wheel scrolling glitching sometimes
> with
>     the virtualized renderers (so far only on Chromium browsers I think).
> I did
>     not want to deal with for now, so mx DataGrid is initially
>     'non-virtualized' and I can come back to this and add virtualized
> renderer
>     support at some later point.
>     I made mx.controls.Image work as a drop-in itemRenderer. This probably
>     needs review, because I had to change its implementation to be more
> nested
>     in terms of native element representation. Perhaps that is not
> necessary,
>     but it does permit something closer to the original for layout (it is
> still
>     not 100% correct for drop-in itemrenderer). This change in Image is not
>     tied to the other changes in the DataGrid classes, it was just an
> attempt
>     to get something working better for 'drop-in' ItemRenderers (e.g.
>     itemRenderer="mx.controls.Image" in this case). So it could be handled
> as
>     separate (either fix any issues or revert).
>
>
>     You can see the current state of this here (the blue rectangles on the
>     right are just mx:Image instances, testing some layout behavior after
>     changes to that component to match Flex originals):
>
>     Flex original (reference implementation):
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Fflex-original%2FMain.html&amp;data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&amp;sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&amp;reserved=0
>
>     Emulation:
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&amp;data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&amp;sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&amp;reserved=0
>
>     I will add this example to mxroyale examples when I push. If you want
> to
>     take a look at the source and both ant and maven builds now, you can
> get
>     that here;
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2FDataGridExample.zip&amp;data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&amp;sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&amp;reserved=0
>
>
>

Reply via email to