Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit - there is still a problem with data transformation - make grid editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before saving". Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
[0] http://demo.phpmyadmin.net/gsoc-aris
-- Aris Feryanto
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
- there is still a problem with data transformation - make grid
editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before saving". Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
I'm also wondering about the "Edit mode". Why not just enter edit when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
IMO yes, it should replace inline edit. I stated it above to make sure everyone who want to test it know that current version is not working well with inline edit.
- there is still a problem with data transformation - make grid
editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before
saving".
Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
I'm also wondering about the "Edit mode". Why not just enter edit when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
When I made this "Edit mode", I was thinking about clicking data with a link, for example foreign key in InnoDb table. We may expect to go to the data associated with the foreign value when clicking the link, don't we?
-- Aris Feryanto
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
IMO yes, it should replace inline edit. I stated it above to make sure everyone who want to test it know that current version is not working well with inline edit.
- there is still a problem with data transformation - make grid
editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before
saving".
Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'm also wondering about the "Edit mode". Why not just enter edit when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
When I made this "Edit mode", I was thinking about clicking data with a link, for example foreign key in InnoDb table. We may expect to go to the data associated with the foreign value when clicking the link, don't we?
Yes. With the current way you are tracking the mouse inside a cell (and display the down arrow), edit mode is needed.
Is is possible to not have an edit mode; then the user, clicking on a data link, would follow the link, but clicking anywhere in the cell would put this cell in edit mode?
We need to find the most intuitive way of editing and I need to be convinced that this is not by clicking.
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
IMO yes, it should replace inline edit. I stated it above to make sure everyone who want to test it know that current version is not working well with inline edit.
- there is still a problem with data transformation - make grid
editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before
saving".
Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
I'm also wondering about the "Edit mode". Why not just
enter edit
when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
When I made this "Edit mode", I was thinking about clicking data
with
a link, for example foreign key in InnoDb table. We may expect to go to the data associated with the foreign value when clicking the link, don't we?
Yes. With the current way you are tracking the mouse inside a cell (and display the down arrow), edit mode is needed.
Is is possible to not have an edit mode; then the user, clicking on a data link, would follow the link, but clicking anywhere in the cell would put this cell in edit mode?
Yes, it is possible. I'll try it. Regarding the data link, how about this: clicking everything in a cell will open the edit box + edit area (area below the drop-down edit box), but if the cell contains link, we provide that link in edit area to really open the link. (Just like clicking on a "link" cell in Google Docs)
We need to find the most intuitive way of editing and I need to be convinced that this is not by clicking.
-- Aris Feryanto
Le 2011-07-22 12:18, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Hi, I just tried Aris's new feature: grid editing (or Edit mode). A few things are not ready, for example ENUM, SET and TEXT editing; however I feel that with this, we won't need inline edit (for rows) any more.
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
IMO yes, it should replace inline edit. I stated it above to make sure everyone who want to test it know that current version is not working well with inline edit.
- there is still a problem with data transformation - make
grid editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before
saving".
Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
Which one will be by default?
I'm also wondering about the "Edit mode". Why not just
enter edit
when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
When I made this "Edit mode", I was thinking about clicking data
with
a link, for example foreign key in InnoDb table. We may expect to go to the data associated with the foreign value when clicking the link, don't we?
Yes. With the current way you are tracking the mouse inside a cell (and display the down arrow), edit mode is needed.
Is is possible to not have an edit mode; then the user, clicking on a data link, would follow the link, but clicking anywhere in the cell would put this cell in edit mode?
Yes, it is possible. I'll try it. Regarding the data link, how about this: clicking everything in a cell will open the edit box + edit area (area below the drop-down edit box), but if the cell contains link, we provide that link in edit area to really open the link. (Just like clicking on a "link" cell in Google Docs)
Good idea; even if this means an extra click, this feature (following a link to foreign table) is probably not used that much.
Do not forget about these: - the title when hovering over the link - the display Options (Relational key / Relational display column).
We need to find the most intuitive way of editing and I need to be convinced that this is not by clicking.
On 23 Jul 2011, at 02:06, Marc Delisle marc@infomarc.info wrote:
Le 2011-07-22 12:18, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message ----- > From: Marc Delisle marc@infomarc.info > > Hi, I just tried Aris's new feature: grid editing (or Edit > mode). A few things are not ready, for example ENUM, SET > and TEXT editing; however I feel that with this, we won't > need inline edit (for rows) any more. >
Hi Marc and all,
Yes, it is still not complete yet. I'm still working on adding support for different data types and fixing bugs. Things I've noticed:
- the feature still does not work well with inline edit
Don't you think that this feature should replace inline edit?
IMO yes, it should replace inline edit. I stated it above to make sure everyone who want to test it know that current version is not working well with inline edit.
- there is still a problem with data transformation - make
grid editing available to those table cell which doesn't have .inline_edit class (e.g., TEXT)
I also planned to add an option to turn on/off "ask before
saving".
Besides these things, the UI and editing mode can be tested in [0]. Any feedback or comment is really appreciated.
Saving is done by clicking outside the cell, right? But it's not explained, should it be?
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
Which one will be by default?
Following the nature of spreadsheet apps, "save all edited cells at once" should be the default IMO.
I'm also wondering about the "Edit mode". Why not just
enter edit
when someone clicks on data? I know that, currently, clicking on data produces row marking and ticks the checkbox, but this could be improved. After all, the most probable intention from a user (with a spreadsheet knowledge) clicking on data is to edit it.
When I made this "Edit mode", I was thinking about clicking data
with
a link, for example foreign key in InnoDb table. We may expect to go to the data associated with the foreign value when clicking the link, don't we?
Yes. With the current way you are tracking the mouse inside a cell (and display the down arrow), edit mode is needed.
Is is possible to not have an edit mode; then the user, clicking on a data link, would follow the link, but clicking anywhere in the cell would put this cell in edit mode?
Yes, it is possible. I'll try it. Regarding the data link, how about this: clicking everything in a cell will open the edit box + edit area (area below the drop-down edit box), but if the cell contains link, we provide that link in edit area to really open the link. (Just like clicking on a "link" cell in Google Docs)
Good idea; even if this means an extra click, this feature (following a link to foreign table) is probably not used that much.
Do not forget about these:
- the title when hovering over the link
- the display Options (Relational key / Relational display column).
Ok, I'll look into that later.
We need to find the most intuitive way of editing and I need to be convinced that this is not by clicking.
-- Aris Feryanto
Hi! If I may...
On Jul 22, 2011, at 12:18 PM, Aris Feryanto aris_feryanto@yahoo.com wrote:
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose:
- auto-save (with/without confirmation)
- save all edited cells at once
I've used an AJAX-enabled application in a similar way (I was selecting from a dropbox) and waiting for the application to update after each selection was slow and frustrating. However, I also just used a different application where I spent a few minutes trying to figure out why my changes weren't being saved. There's a tiny Save button in the corner.
Anyway, the point is that I like giving the user the power to chose. I thought about it and think I'd prefer to see the choice as a checkbox near the top of the results; it wouldn't make sense to put it as a config.inc.php setting because I'd want to change it depending on the type of fields I'm editing.
Hope that helps.
~Isaac
Le 2011-07-23 12:34, Isaac Bennetch a écrit :
Hi! If I may...
On Jul 22, 2011, at 12:18 PM, Aris Feryanto aris_feryanto@yahoo.com wrote:
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit :
----- Original Message ----- > From: Marc Delisle marc@infomarc.info >
Also, if we compare with a spreadsheet program, saving is not done when exiting a cell, it's done by an explicit click (for example on a Disk button). The user might want to change many columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
I've used an AJAX-enabled application in a similar way (I was selecting from a dropbox) and waiting for the application to update after each selection was slow and frustrating. However, I also just used a different application where I spent a few minutes trying to figure out why my changes weren't being saved. There's a tiny Save button in the corner.
The problem was that the Save button was too small or misplaced in this application.
Anyway, the point is that I like giving the user the power to chose. I thought about it and think I'd prefer to see the choice as a checkbox near the top of the results; it wouldn't make sense to put it as a config.inc.php setting because I'd want to change it depending on the type of fields I'm editing.
This would mean we would have two mechanisms for user preferences, which can be confusing. Also, if someone always prefers the choice that is not checked by default, he will complain.
Hope that helps.
~Isaac
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi,
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-23 12:34, Isaac Bennetch a écrit :
Hi! If I may...
On Jul 22, 2011, at 12:18 PM, Aris Feryanto aris_feryanto@yahoo.com wrote:
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 09:16, Aris Feryanto a écrit : > ----- Original Message ----- >> From: Marc Delisle marc@infomarc.info >>
Also, if we compare with a spreadsheet program, saving is
not
done when exiting a cell, it's done by an explicit
click (for
example on a Disk button). The user might want to change
many
columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
I've used an AJAX-enabled application in a similar way (I was selecting from a dropbox) and waiting for the application to update after each selection was slow and frustrating. However, I also just used a different application where I spent a few minutes trying to figure out why my changes weren't being saved. There's a tiny Save button in the corner.
The problem was that the Save button was too small or misplaced in this application.
I just pushed code to my git repo. I added ability to save all edited cells at once (configurable via Settings -> Main frame -> Browse mode -> Save all edited cells at once). But there are still some problems that I'm currently trying to solve: - the links for "relation" cells are gone after we save the edited cells - all TEXT data type is considered as edited, even when we do not do any editing Other than these, I think the user interface and way of editing are ready to be tested.
Anyway, the point is that I like giving the user the power to chose. I thought about it and think I'd prefer to see the choice as a checkbox near the top of the results; it wouldn't make sense to put it as a config.inc.php setting because I'd want to change it depending on the type of fields I'm editing.
This would mean we would have two mechanisms for user preferences, which can be confusing. Also, if someone always prefers the choice that is not checked by default, he will complain.
Currently, I only add the configuration in the Settings page.
If you have some time, please try the demo at http://demo.phpmyadmin.net/gsoc-aris and I really appreciate if there is any comment or suggestion.
-- Aris Feryanto
Aris Feryanto a écrit :
I just pushed code to my git repo. I added ability to save all edited cells at once (configurable via Settings -> Main frame -> Browse mode -> Save all edited cells at once). But there are still some problems that I'm currently trying to solve: - the links for "relation" cells are gone after we save the edited cells - all TEXT data type is considered as edited, even when we do not do any editing Other than these, I think the user interface and way of editing are ready to be tested.
Aris, I tested your tree (0d422a3a12d1734115c7a0e4b410dfc35d453aa2). In the default setting of saving at once (with the "Save edited data" button) my simple test of sakila.actor worked fine.
With the opposite setting, when trying to save my change to last_name, I get: $this_field is not defined in makegrid.js line 970.
Currently, I only add the configuration in the Settings page.
It will be needed also in /setup.
If you have some time, please try the demo at http://demo.phpmyadmin.net/gsoc-aris and I really appreciate if there is any comment or suggestion.
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
> I just pushed code to my git repo. I added ability to save all edited
cells at once (configurable via Settings -> Main frame -> Browse mode -> Save all edited cells at once). But there are still some problems that I'm currently trying to solve: - the links for
"relation" cells
are gone after we save the edited cells - all TEXT data type is considered as edited, even when we do not do any editing Other than these, I think the user interface and way of editing are ready to be tested.
Aris, I tested your tree (0d422a3a12d1734115c7a0e4b410dfc35d453aa2). In the default setting of saving at once (with the "Save edited data" button)
my simple test of sakila.actor worked fine.
With the opposite setting, when trying to save my change to last_name, I get: $this_field is not defined in makegrid.js line 970.
Thank you for noticing this. I just fixed it and pushed the changes to my repo.
Please check the new code and let me know what do you think about it.
Currently, I only add the configuration in the Settings page.
It will be needed also in /setup.
I have added the /setup in my commit before.
If you have some time, please try the demo at http://demo.phpmyadmin.net/gsoc-aris and I really appreciate if there is any comment or suggestion.
-- Aris Feryanto
Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
I just pushed code to my git repo. I added ability to save all edited cells at once (configurable via Settings -> Main frame -> Browse mode -> Save all edited cells at once). But there are still some problems that I'm currently trying to solve: - the links for
"relation" cells
are gone after we save the edited cells - all TEXT data type is considered as edited, even when we do not do any editing Other than these, I think the user interface and way of editing are ready to be tested.
Aris, I tested your tree (0d422a3a12d1734115c7a0e4b410dfc35d453aa2). In the default setting of saving at once (with the "Save edited data" button)
my simple test of sakila.actor worked fine.
With the opposite setting, when trying to save my change to last_name, I get: $this_field is not defined in makegrid.js line 970.
Thank you for noticing this. I just fixed it and pushed the changes to my repo.
I confirm the fix.
Please check the new code and let me know what do you think about it.
I am not familiar with this kind of syntax: postEditedCell: function() {
Could you explain why this was needed?
Other remarks:
1. After saving all at once, there is an empty div with class notice about the displayed UPDATE statement.
2. I wonder about the best place to display the "Save edited data" button. Maybe on the data row (next to the other actions link)?
3. I hope that we'll get the OK from other developers to remove the row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
4. With this feature, we have the same problems as with inline edit, such as:
4.1 (minor) If there is a sort over one column then this column is edited for one row, the sorting order is no longer respected
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Currently, I only add the configuration in the Settings page.
It will be needed also in /setup.
I have added the /setup in my commit before.
Great.
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
> I just pushed code to my git repo. I added ability to save all
edited
cells at once (configurable via Settings -> Main frame ->
Browse mode
-> Save all edited cells at once). But there are still some
problems
that I'm currently trying to solve: - the links for
"relation" cells
are gone after we save the edited cells - all TEXT data type is considered as edited, even when we do not do any editing Other
than
these, I think the user interface and way of editing are ready to
be
tested.
Aris, I tested your tree (0d422a3a12d1734115c7a0e4b410dfc35d453aa2). In the default setting of saving at once (with the "Save edited
data" button)
my simple test of sakila.actor worked fine.
With the opposite setting, when trying to save my change to last_name,
I
get: $this_field is not defined in makegrid.js line 970.
Thank you for noticing this. I just fixed it and pushed the changes to my
repo.
I confirm the fix.
Please check the new code and let me know what do you think about it.
I am not familiar with this kind of syntax: postEditedCell: function() {
Could you explain why this was needed?
This is one way to implement OO-like structure in javascript. In makegrid.js, I implement grid-related functions in that way.
Other remarks:
- After saving all at once, there is an empty div with class notice
about the displayed UPDATE statement.
Fixed.
- I wonder about the best place to display the "Save edited data"
button. Maybe on the data row (next to the other actions link)?
Is "next to the other actions link" means somewhere near "Edit" or "Delete" button?
- I hope that we'll get the OK from other developers to remove the row
inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
- With this feature, we have the same problems as with inline edit,
such as:
4.1 (minor) If there is a sort over one column then this column is edited for one row, the sorting order is no longer respected
IMO, this is not a problem, since user can see the updated value rather than the value disappear directly to other page.
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
I just pushed my code to my git repo and the demo is already available in [0]. Any comment or suggestion is really appreciated.
[0] http://demo.phpmyadmin.net/gsoc-aris
-- Aris Feryanto
Le 2011-07-29 11:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Other remarks:
- After saving all at once, there is an empty div with class
notice about the displayed UPDATE statement.
Fixed.
- I wonder about the best place to display the "Save edited data"
button. Maybe on the data row (next to the other actions link)?
Is "next to the other actions link" means somewhere near "Edit" or "Delete" button?
Yes.
- I hope that we'll get the OK from other developers to remove the
row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
- With this feature, we have the same problems as with inline
edit, such as:
4.1 (minor) If there is a sort over one column then this column is edited for one row, the sorting order is no longer respected
IMO, this is not a problem, since user can see the updated value rather than the value disappear directly to other page.
Good point.
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old unique key.
About multi-row actions, here is a scenario: - open sakila.actor - use the checkbox on two rows - in the "With selected", click Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row, change the unique key and save - use the checkbox on two rows, including the one you just grid-edited - in the "With selected", click Export - problem: incorrect generated query for the grid-edited row
About remark 4.3, the Edit link still points to the old data and fails, in the case of a table lacking a unique key.
----- Original Message -----
From: Marc Delisle marc@infomarc.info Le 2011-07-29 11:11, Aris Feryanto a écrit :
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Other remarks:
- After saving all at once, there is an empty div with class
notice about the displayed UPDATE statement.
Fixed.
- I wonder about the best place to display the "Save edited
data"
button. Maybe on the data row (next to the other actions link)?
Is "next to the other actions link" means somewhere near
"Edit" or
"Delete" button?
Yes.
Does it mean the buttons will be shown per row? IMO, single button to save all edited fields will be the best.
- I hope that we'll get the OK from other developers to remove the
row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
- With this feature, we have the same problems as with inline
edit, such as:
4.1 (minor) If there is a sort over one column then this column is edited for one row, the sorting order is no longer respected
IMO, this is not a problem, since user can see the updated value rather than the value disappear directly to other page.
Good point.
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old unique key.
It's weird, since this works in my test. Could you please check this again?
About multi-row actions, here is a scenario:
open sakila.actor
use the checkbox on two rows
in the "With selected", click Export
it works: you are seeing these keys in the generated query
go back to browsing sakila.actor
grid edit one row, change the unique key and save
use the checkbox on two rows, including the one you just grid-edited
in the "With selected", click Export
problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data and fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you check this again?
Thank you. :)
-- Aris Feryanto
Le 2011-07-31 13:15, Aris Feryanto a écrit :
- I wonder about the best place to display the "Save edited
data"
button. Maybe on the data row (next to the other actions link)?
Is "next to the other actions link" means somewhere near
"Edit" or
"Delete" button?
Yes.
Does it mean the buttons will be shown per row? IMO, single button to save all edited fields will be the best.
Ok, I was not thinking about using this feature for multi-row editing. Forget my remark, sorry.
- I hope that we'll get the OK from other developers to remove
the row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
Still waiting for input from other developers...
- With this feature, we have the same problems as with inline
edit, such as:
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old unique key.
It's weird, since this works in my test. Could you please check this again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
About multi-row actions, here is a scenario: - open sakila.actor - use the checkbox on two rows - in the "With selected", click Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row, change the
unique key and save - use the checkbox on two rows, including the one you just grid-edited - in the "With selected", click Export - problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data and fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you check this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Thank you. :)
5. Just found out another problem, when the configuration AjaxEnable is set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on sakila.actor, I cannot change the actor_id then click "Save edited data". Look what is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id` =2
From: Marc Delisle marc@infomarc.info
Le 2011-07-31 13:15, Aris Feryanto a écrit :
- I hope that we'll get the OK from other developers to
remove
the row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
Still waiting for input from other developers...
It seems there is no objection about this. Instead, positive feedback from other phpMyAdmin developers.
- With this feature, we have the same problems as with inline
edit, such as:
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old unique key.
It's weird, since this works in my test. Could you please check this again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
Fixed
About multi-row actions, here is a scenario: - open sakila.actor - use the checkbox on two rows - in the "With selected", click Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row, change the
unique key and save - use the checkbox on two rows, including the one you just grid-edited - in the "With selected", click
Export -
problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data and fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you check this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Fixed.
- Just found out another problem, when the configuration AjaxEnable is
set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on sakila.actor, I cannot change the actor_id then click "Save edited data". Look what is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id` =2
Regarding the AjaxEnable setting, should the grid editing works when AjaxEnable is set to off?
All the fixes were pushed to my git repo and available in the demo server: http://demo.phpmyadmin.net/gsoc-aris
-- Aris Feryanto
Aris Feryanto a écrit :
From: Marc Delisle marc@infomarc.info
Le 2011-07-31 13:15, Aris Feryanto a écrit :
- I hope that we'll get the OK from other developers to
remove
the row inline edit feature, because with the current code,
3.1 we have two features to do almost the same thing 3.2 currently, clicking on inline edit then on a cell activates the grid editing!
I hope so. Any objections?
Still waiting for input from other developers...
It seems there is no objection about this. Instead, positive feedback from other phpMyAdmin developers.
Yes. Can you remove the row inline edit feature from your tree?
- With this feature, we have the same problems as with inline
edit, such as:
4.2 (major) For tables with a unique key, if this key is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
4.3 (major) For tables without a unique key, if any column is edited, the Edit, Copy and Delete links no longer contain a valid where_clause parameter and the multi-rows actions at the bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old unique key.
It's weird, since this works in my test. Could you please check this again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
Fixed
Confirmed.
About multi-row actions, here is a scenario: - open sakila.actor - use the checkbox on two rows - in the "With selected", click Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row, change the
unique key and save - use the checkbox on two rows, including the one you just grid-edited - in the "With selected", click
Export -
problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data and fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you check this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Fixed.
Problem 4.3 exists in your current tree. Tested with the Edit link on the sakila.actor table by changing the actor_id.
- Just found out another problem, when the configuration AjaxEnable is
set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on sakila.actor, I cannot change the actor_id then click "Save edited data". Look what is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id` =2
Regarding the AjaxEnable setting, should the grid editing works when AjaxEnable is set to off?
No.
6. As suggested by Dieter and confirmed by Michal, please set this in config.default.php:
$cfg['SaveCellsAtOnce'] = false;
Indeed it seems more prudent to auto-save, even it means more requests in case of many changes.
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
From: Marc Delisle marc@infomarc.info
Le 2011-07-31 13:15, Aris Feryanto a écrit :
> 3. I hope that we'll get the OK from other
developers to
remove
> the row inline edit feature, because with the current
code,
> > 3.1 we have two features to do almost the same thing
3.2
> currently, clicking on inline edit then on a cell
activates the
> grid editing! I hope so. Any objections?
Still waiting for input from other developers...
It seems there is no objection about this. Instead, positive feedback from
other phpMyAdmin developers.
Yes. Can you remove the row inline edit feature from your tree?
Sure. I will work on this.
> 4. With this feature, we have the same problems as
with inline
> edit, such as: > > 4.2 (major) For tables with a unique key, if this key
is
> edited, the Edit, Copy and Delete links no longer
contain a
> valid where_clause parameter and the multi-rows
actions at the
> bottom (with selected) no longer work. > > 4.3 (major) For tables without a unique key, if any
column is
> edited, the Edit, Copy and Delete links no longer
contain a
> valid where_clause parameter and the multi-rows
actions at the
> bottom (with selected) no longer work.
Two problems above were fixed.
It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old
unique
key.
It's weird, since this works in my test. Could you please
check this
again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
Fixed
Confirmed.
About multi-row actions, here is a scenario: - open
sakila.actor -
use the checkbox on two rows - in the "With
selected", click
Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row, change
the
unique key and save - use the checkbox on two rows, including
the
one you just grid-edited - in the "With selected",
click
Export -
problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data
and
fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you
check
this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Fixed.
Problem 4.3 exists in your current tree. Tested with the Edit link on the sakila.actor table by changing the actor_id.
In my test, grid-editing the actor_id in sakila.actor table and then click the Edit link direct me to correct page, where I can edit the row. Btw, remark 4.3 is for tables without a unique key, while actor_id is primary key. Is this correct?
- Just found out another problem, when the configuration AjaxEnable is
set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on
sakila.actor,
I cannot change the actor_id then click "Save edited data".
Look what
is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id`
=2
Regarding the AjaxEnable setting, should the grid editing works when
AjaxEnable is set to off?
No.
I will work on this.
- As suggested by Dieter and confirmed by Michal, please set this in
config.default.php:
$cfg['SaveCellsAtOnce'] = false;
Indeed it seems more prudent to auto-save, even it means more requests in case of many changes.
Updated and pushed to my git.
-- Aris Feryanto
Aris Feryanto a écrit :
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
From: Marc Delisle marc@infomarc.info Le 2011-07-31 13:15, Aris Feryanto a écrit :
>> 3. I hope that we'll get the OK from other
developers to
remove
>> the row inline edit feature, because with the current
code,
>> 3.1 we have two features to do almost the same thing
3.2
>> currently, clicking on inline edit then on a cell
activates the
>> grid editing! > I hope so. Any objections?
Still waiting for input from other developers...
It seems there is no objection about this. Instead, positive feedback from
other phpMyAdmin developers.
Yes. Can you remove the row inline edit feature from your tree?
Sure. I will work on this.
>> 4. With this feature, we have the same problems as
with inline
>> edit, such as: >> >> 4.2 (major) For tables with a unique key, if this key
is
>> edited, the Edit, Copy and Delete links no longer
contain a
>> valid where_clause parameter and the multi-rows
actions at the
>> bottom (with selected) no longer work. >> >> 4.3 (major) For tables without a unique key, if any
column is
>> edited, the Edit, Copy and Delete links no longer
contain a
>> valid where_clause parameter and the multi-rows
actions at the
>> bottom (with selected) no longer work. > Two problems above were fixed. It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old
unique
key.
It's weird, since this works in my test. Could you please
check this
again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
Fixed
Confirmed.
About multi-row actions, here is a scenario: - open
sakila.actor -
use the checkbox on two rows - in the "With
selected", click
Export - it works: you are seeing these keys in the generated query
- go back to browsing sakila.actor - grid edit one row,
change
the
unique key and save - use the checkbox on two rows, including
the
one you just grid-edited - in the "With selected",
click
Export -
problem: incorrect generated query for the grid-edited row
Yap. It still generates wrong export. I'll fix this.
About remark 4.3, the Edit link still points to the old data
and
fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you
check
this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Fixed.
Problem 4.3 exists in your current tree. Tested with the Edit link on the sakila.actor table by changing the actor_id.
In my test, grid-editing the actor_id in sakila.actor table and then click the Edit link direct me to correct page, where I can edit the row. Btw, remark 4.3 is for tables without a unique key, while actor_id is primary key. Is this correct?
To reproduce the 4.3 case, use a copy of the actor table, on which you remove the primary key.
- Just found out another problem, when the configuration
AjaxEnable is set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on
sakila.actor,
I cannot change the actor_id then click "Save edited data".
Look what
is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id`
=2
Regarding the AjaxEnable setting, should the grid editing works when
AjaxEnable is set to off?
No.
I will work on this.
- As suggested by Dieter and confirmed by Michal, please set this
in config.default.php:
$cfg['SaveCellsAtOnce'] = false;
Indeed it seems more prudent to auto-save, even it means more requests in case of many changes.
Updated and pushed to my git.
From: Marc Delisle marc@infomarc.info
Problem 4.3 exists in your current tree. Tested with the Edit link on the sakila.actor table by changing the actor_id.
In my test, grid-editing the actor_id in sakila.actor table and then click the Edit link direct me to correct page, where I can edit the row. Btw, remark 4.3 is for tables without a unique key, while actor_id is primary key. Is this correct?
To reproduce the 4.3 case, use a copy of the actor table, on which you remove the primary key.
Confirmed and will work on this.
-- Aris Feryanto
2011/7/27 Aris Feryanto aris_feryanto@yahoo.com:
Hi,
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-23 12:34, Isaac Bennetch a écrit :
Hi! If I may...
On Jul 22, 2011, at 12:18 PM, Aris Feryanto aris_feryanto@yahoo.com wrote:
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Le 2011-07-22 10:11, Aris Feryanto a écrit :
----- Original Message ----- > From: Marc Delisle marc@infomarc.info > > Le 2011-07-22 09:16, Aris Feryanto a écrit : >> ----- Original Message ----- >>> From: Marc Delisle marc@infomarc.info >>> > > > Also, if we compare with a spreadsheet program, saving is
not
> done when exiting a cell, it's done by an explicit
click (for
> example on a Disk button). The user might want to change
many
> columns before saving.
Great. I think it's good to have the feature to save all edited columns at once.
So you'll change the interface to avoid auto-saving after clicking outside of the modified cell?
I'll try to provide these two options for the user to choose: - auto-save (with/without confirmation) - save all edited cells at once
>
I've used an AJAX-enabled application in a similar way (I was selecting from a dropbox) and waiting for the application to update after each selection was slow and frustrating. However, I also just used a different application where I spent a few minutes trying to figure out why my changes weren't being saved. There's a tiny Save button in the corner.
The problem was that the Save button was too small or misplaced in this application.
I just pushed code to my git repo. I added ability to save all edited cells at once (configurable via Settings -> Main frame -> Browse mode -> Save all edited cells at once). But there are still some problems that I'm currently trying to solve:
- the links for "relation" cells are gone after we save the edited cells
- all TEXT data type is considered as edited, even when we do not do any editing
Other than these, I think the user interface and way of editing are ready to be tested.
Anyway, the point is that I like giving the user the power to chose. I thought about it and think I'd prefer to see the choice as a checkbox near the top of the results; it wouldn't make sense to put it as a config.inc.php setting because I'd want to change it depending on the type of fields I'm editing.
This would mean we would have two mechanisms for user preferences, which can be confusing. Also, if someone always prefers the choice that is not checked by default, he will complain.
Currently, I only add the configuration in the Settings page.
If you have some time, please try the demo at http://demo.phpmyadmin.net/gsoc-aris and I really appreciate if there is any comment or suggestion.
-- Aris Feryanto
Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi all,
I agree with the proposed solutions :
- clicking a cell to activate edit mode (with an exception for cells that contain a link) - choice of autosave/save all with a checkbox, but I would prefer the autosave option as a default. (but I guess this could be set in user preferences) - if the grid editing works fine it can replace inline editing. I don't see a use for it anymore then.
Kind regards,
Dieter
Hi
Dne Tue, 2 Aug 2011 13:41:41 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
I agree with the proposed solutions :
- clicking a cell to activate edit mode (with an exception for cells
that contain a link)
- choice of autosave/save all with a checkbox, but I would prefer the
autosave option as a default. (but I guess this could be set in user preferences)
- if the grid editing works fine it can replace inline editing. I
don't see a use for it anymore then.
Sounds perfectly reasonable to me as well.
-
Aris Feryanto -
Dieter Adriaenssens -
Isaac Bennetch -
Marc Delisle -
Michal Čihař