You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2020/04/29 23:41:45 UTC
mx DataGrid / mx AdvancedDataGrid - if you use them in MXRoyale...
please read this and reply
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):
http://interactionscript.com/royale/mx-grids/flex-original/Main.html
Emulation:
http://interactionscript.com/royale/mx-grids/emulation/js-release/index.html
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;
http://interactionscript.com/royale/mx-grids/emulation/DataGridExample.zip
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Greg Dove <gr...@gmail.com>.
First up I need to fix the build because I missed something... on it.
On Fri, May 15, 2020 at 11:37 PM Greg Dove <gr...@gmail.com> wrote:
>
> I've not been using ADG, I am using mx DG. I was just applying the same
> improvements wherever I could to both.
>
> Hopefully you should see only improvements, but it really depends on how
> you were already using it. A bunch of things that work in that online demo
> were not working well prior to these latest changes.
> There are still a few things to iron out over time. rollovers in the
> searchable headers, and row level rollovers in the grid etc along with the
> other things I mentioned. But I've focused on functional issues mainly.
>
> I have not tested the advanced features of ADG with column groups, or
> itemEditing yet. I assume that works, but don't know for sure. Having an
> example of that in asjs would be great if you ever get time for that.
>
> Let me know if you want to team up on some of the improvements I have
> mentioned for these (gradually over time), because for most of the things I
> did so far, I made changes for both of them (I definitely harvested a lot
> of Alex's work on ADG and applied it directly to mx DataGrid to start with,
> which was a great base). Using the 'identical' Flex comparator reference is
> helpful as well, I think.
> If you see anything untoward, definitely let me know.
>
>
>
>
>
>
>
>
> On Fri, May 15, 2020 at 11:15 PM Yishay Weiss <yi...@hotmail.com>
> wrote:
>
>> Hi Greg,
>>
>> I’m currently using AdvancedDataGrid. These sound like good improvements.
>> Anything in particular I need to watch out for?
>>
>> Thanks.
>>
>> From: Greg Dove<ma...@gmail.com>
>> Sent: Friday, May 15, 2020 11:20 AM
>> To: Apache Royale Development<ma...@royale.apache.org>
>> Subject: Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
>> MXRoyale... please read this and reply
>>
>> I have more updates coming for these two emulation DataGrids, adding
>> support for changing things at runtime as well as bugfixes (my main need
>> is
>> mxDataGrid, but I propagated fixes/improvements to ADG, or shared them
>> wherever possible).
>>
>>
>> REFERENCE (FLEX VERSION):
>> http://interactionscript.com/royale/mx-grids/flex-original/Main.html
>>
>> LATEST (ROYALE):
>>
>> http://interactionscript.com/royale/mx-grids/emulation/js-release/index.html
>>
>>
>>
>>
>> Fixes/Imrpovements to:
>> -multiple selection behaviour was not working right
>> -re-selection of correct renderers after sort is applied
>> -header resize dragging if the horizontal scroll is not at zero.
>> -support scrollpolicy dynamic changes
>> -DropInRenderer mouse events bead added if needed
>> -Fix for issue in js-release build with some uids not working (affects
>> some
>> selection logic)
>> -added the caret indicator to mxDataGrid (this is supposed to be keyboard
>> only, I think, but I added it for mouse events same as ADG for now)
>>
>> probably some other little things too...
>>
>> I will be pushing these changes shortly, but welcome any feedback. The
>> above test/demo will be updated in the DataGrids example in mxroyale
>> examples.
>>
>> There are opportunities to consolidate the code more in the future between
>> these two, but for now, I am just aiming to get things working in the mx
>> DataGrid. I will be adding item editing support to mx DataGrid alsp before
>> too long (I will use what is already done for ADG as much as I can). I
>> will
>> probably look into keyboard controls and focus management after that (or
>> this might be necessary in parallel ... I will see).
>> Other things of note:
>> -I will work to improve the column/header resize UI/UX at some point (not
>> urgent for me yet)
>> -Currently I used a non-virtual item renderer for mx DataGrid (I was
>> seeing
>> some glitches in the virtualized behaviour in ADG) but I will also aim to
>> swap that back to virtual lists in the near future, once I get a change to
>> work on that.
>> I don't have a working example of the advanced features of ADG. If anyone
>> has one, it would be great to add one to the examples.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 4, 2020 at 6:13 PM Greg Dove <gr...@gmail.com> wrote:
>>
>> >
>> > I did end up waiting a few more days, as I had to also add support for
>> > dynamic column swapping. ADG gets support for this too. I pushed that
>> > single commit, along with a new demo.
>> >
>> >
>> >
>> >
>> > On Thu, Apr 30, 2020 at 12:10 PM Greg Dove <gr...@gmail.com> wrote:
>> >
>> >>
>> >> 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 <ah...@adobe.com.invalid>
>> >> 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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
>> >>>
>> >>> Emulation:
>> >>>
>> >>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
>> >>>
>> >>>
>> >>>
>>
>>
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Greg Dove <gr...@gmail.com>.
I've not been using ADG, I am using mx DG. I was just applying the same
improvements wherever I could to both.
Hopefully you should see only improvements, but it really depends on how
you were already using it. A bunch of things that work in that online demo
were not working well prior to these latest changes.
There are still a few things to iron out over time. rollovers in the
searchable headers, and row level rollovers in the grid etc along with the
other things I mentioned. But I've focused on functional issues mainly.
I have not tested the advanced features of ADG with column groups, or
itemEditing yet. I assume that works, but don't know for sure. Having an
example of that in asjs would be great if you ever get time for that.
Let me know if you want to team up on some of the improvements I have
mentioned for these (gradually over time), because for most of the things I
did so far, I made changes for both of them (I definitely harvested a lot
of Alex's work on ADG and applied it directly to mx DataGrid to start with,
which was a great base). Using the 'identical' Flex comparator reference is
helpful as well, I think.
If you see anything untoward, definitely let me know.
On Fri, May 15, 2020 at 11:15 PM Yishay Weiss <yi...@hotmail.com>
wrote:
> Hi Greg,
>
> I’m currently using AdvancedDataGrid. These sound like good improvements.
> Anything in particular I need to watch out for?
>
> Thanks.
>
> From: Greg Dove<ma...@gmail.com>
> Sent: Friday, May 15, 2020 11:20 AM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
> MXRoyale... please read this and reply
>
> I have more updates coming for these two emulation DataGrids, adding
> support for changing things at runtime as well as bugfixes (my main need is
> mxDataGrid, but I propagated fixes/improvements to ADG, or shared them
> wherever possible).
>
>
> REFERENCE (FLEX VERSION):
> http://interactionscript.com/royale/mx-grids/flex-original/Main.html
>
> LATEST (ROYALE):
>
> http://interactionscript.com/royale/mx-grids/emulation/js-release/index.html
>
>
>
>
> Fixes/Imrpovements to:
> -multiple selection behaviour was not working right
> -re-selection of correct renderers after sort is applied
> -header resize dragging if the horizontal scroll is not at zero.
> -support scrollpolicy dynamic changes
> -DropInRenderer mouse events bead added if needed
> -Fix for issue in js-release build with some uids not working (affects some
> selection logic)
> -added the caret indicator to mxDataGrid (this is supposed to be keyboard
> only, I think, but I added it for mouse events same as ADG for now)
>
> probably some other little things too...
>
> I will be pushing these changes shortly, but welcome any feedback. The
> above test/demo will be updated in the DataGrids example in mxroyale
> examples.
>
> There are opportunities to consolidate the code more in the future between
> these two, but for now, I am just aiming to get things working in the mx
> DataGrid. I will be adding item editing support to mx DataGrid alsp before
> too long (I will use what is already done for ADG as much as I can). I will
> probably look into keyboard controls and focus management after that (or
> this might be necessary in parallel ... I will see).
> Other things of note:
> -I will work to improve the column/header resize UI/UX at some point (not
> urgent for me yet)
> -Currently I used a non-virtual item renderer for mx DataGrid (I was seeing
> some glitches in the virtualized behaviour in ADG) but I will also aim to
> swap that back to virtual lists in the near future, once I get a change to
> work on that.
> I don't have a working example of the advanced features of ADG. If anyone
> has one, it would be great to add one to the examples.
>
>
>
>
>
>
>
>
> On Mon, May 4, 2020 at 6:13 PM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > I did end up waiting a few more days, as I had to also add support for
> > dynamic column swapping. ADG gets support for this too. I pushed that
> > single commit, along with a new demo.
> >
> >
> >
> >
> > On Thu, Apr 30, 2020 at 12:10 PM Greg Dove <gr...@gmail.com> wrote:
> >
> >>
> >> 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 <ah...@adobe.com.invalid>
> >> 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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
> >>>
> >>> Emulation:
> >>>
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
> >>>
> >>>
> >>>
>
>
RE: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Yishay Weiss <yi...@hotmail.com>.
Hi Greg,
I’m currently using AdvancedDataGrid. These sound like good improvements. Anything in particular I need to watch out for?
Thanks.
From: Greg Dove<ma...@gmail.com>
Sent: Friday, May 15, 2020 11:20 AM
To: Apache Royale Development<ma...@royale.apache.org>
Subject: Re: mx DataGrid / mx AdvancedDataGrid - if you use them in MXRoyale... please read this and reply
I have more updates coming for these two emulation DataGrids, adding
support for changing things at runtime as well as bugfixes (my main need is
mxDataGrid, but I propagated fixes/improvements to ADG, or shared them
wherever possible).
REFERENCE (FLEX VERSION):
http://interactionscript.com/royale/mx-grids/flex-original/Main.html
LATEST (ROYALE):
http://interactionscript.com/royale/mx-grids/emulation/js-release/index.html
Fixes/Imrpovements to:
-multiple selection behaviour was not working right
-re-selection of correct renderers after sort is applied
-header resize dragging if the horizontal scroll is not at zero.
-support scrollpolicy dynamic changes
-DropInRenderer mouse events bead added if needed
-Fix for issue in js-release build with some uids not working (affects some
selection logic)
-added the caret indicator to mxDataGrid (this is supposed to be keyboard
only, I think, but I added it for mouse events same as ADG for now)
probably some other little things too...
I will be pushing these changes shortly, but welcome any feedback. The
above test/demo will be updated in the DataGrids example in mxroyale
examples.
There are opportunities to consolidate the code more in the future between
these two, but for now, I am just aiming to get things working in the mx
DataGrid. I will be adding item editing support to mx DataGrid alsp before
too long (I will use what is already done for ADG as much as I can). I will
probably look into keyboard controls and focus management after that (or
this might be necessary in parallel ... I will see).
Other things of note:
-I will work to improve the column/header resize UI/UX at some point (not
urgent for me yet)
-Currently I used a non-virtual item renderer for mx DataGrid (I was seeing
some glitches in the virtualized behaviour in ADG) but I will also aim to
swap that back to virtual lists in the near future, once I get a change to
work on that.
I don't have a working example of the advanced features of ADG. If anyone
has one, it would be great to add one to the examples.
On Mon, May 4, 2020 at 6:13 PM Greg Dove <gr...@gmail.com> wrote:
>
> I did end up waiting a few more days, as I had to also add support for
> dynamic column swapping. ADG gets support for this too. I pushed that
> single commit, along with a new demo.
>
>
>
>
> On Thu, Apr 30, 2020 at 12:10 PM Greg Dove <gr...@gmail.com> wrote:
>
>>
>> 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 <ah...@adobe.com.invalid>
>> 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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
>>>
>>> Emulation:
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
>>>
>>>
>>>
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Greg Dove <gr...@gmail.com>.
I have more updates coming for these two emulation DataGrids, adding
support for changing things at runtime as well as bugfixes (my main need is
mxDataGrid, but I propagated fixes/improvements to ADG, or shared them
wherever possible).
REFERENCE (FLEX VERSION):
http://interactionscript.com/royale/mx-grids/flex-original/Main.html
LATEST (ROYALE):
http://interactionscript.com/royale/mx-grids/emulation/js-release/index.html
Fixes/Imrpovements to:
-multiple selection behaviour was not working right
-re-selection of correct renderers after sort is applied
-header resize dragging if the horizontal scroll is not at zero.
-support scrollpolicy dynamic changes
-DropInRenderer mouse events bead added if needed
-Fix for issue in js-release build with some uids not working (affects some
selection logic)
-added the caret indicator to mxDataGrid (this is supposed to be keyboard
only, I think, but I added it for mouse events same as ADG for now)
probably some other little things too...
I will be pushing these changes shortly, but welcome any feedback. The
above test/demo will be updated in the DataGrids example in mxroyale
examples.
There are opportunities to consolidate the code more in the future between
these two, but for now, I am just aiming to get things working in the mx
DataGrid. I will be adding item editing support to mx DataGrid alsp before
too long (I will use what is already done for ADG as much as I can). I will
probably look into keyboard controls and focus management after that (or
this might be necessary in parallel ... I will see).
Other things of note:
-I will work to improve the column/header resize UI/UX at some point (not
urgent for me yet)
-Currently I used a non-virtual item renderer for mx DataGrid (I was seeing
some glitches in the virtualized behaviour in ADG) but I will also aim to
swap that back to virtual lists in the near future, once I get a change to
work on that.
I don't have a working example of the advanced features of ADG. If anyone
has one, it would be great to add one to the examples.
On Mon, May 4, 2020 at 6:13 PM Greg Dove <gr...@gmail.com> wrote:
>
> I did end up waiting a few more days, as I had to also add support for
> dynamic column swapping. ADG gets support for this too. I pushed that
> single commit, along with a new demo.
>
>
>
>
> On Thu, Apr 30, 2020 at 12:10 PM Greg Dove <gr...@gmail.com> wrote:
>
>>
>> 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 <ah...@adobe.com.invalid>
>> 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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
>>>
>>> Emulation:
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
>>>
>>>
>>>
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Greg Dove <gr...@gmail.com>.
I did end up waiting a few more days, as I had to also add support for
dynamic column swapping. ADG gets support for this too. I pushed that
single commit, along with a new demo.
On Thu, Apr 30, 2020 at 12:10 PM Greg Dove <gr...@gmail.com> wrote:
>
> 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 <ah...@adobe.com.invalid>
> 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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
>>
>> Emulation:
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
>>
>>
>>
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@adobe.com.invalid>
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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
>
> Emulation:
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0
>
>
>
Re: mx DataGrid / mx AdvancedDataGrid - if you use them in
MXRoyale... please read this and reply
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@gmail.com> 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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=17NEm%2BvOqLXer7EcLmpdJ3qEZegJBY7lViKnSXmOjZk%3D&reserved=0
Emulation:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Finteractionscript.com%2Froyale%2Fmx-grids%2Femulation%2Fjs-release%2Findex.html&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8YjuLwGd%2FOlqLXURhD0bJZz2Da12AZyUIzh9qBo1MhQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C66ad5498632d4a7d613408d7ec96ee72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238005298074875&sdata=8y6W%2FuVbh4QCDokw3WaPOdbkFj86MB7xXw1%2BUYWLPmg%3D&reserved=0