[Please comment] Cell editing, changing API (2.0)

I was trying to finish cell editing API over the last two weeks and, basically, failed. Not that it is impossible to complete, but I finally decided that the API itself should be changed, as it currently looks too much complicated, even for myself. If you have any opinion on this topic - please raise your voice now, especially if you have some ideas on how cell editing API should look like.

With the current approach (beta2) there is a separate 'editor' template which replaces 'cell' template for the current cell during editing time. After the cell data is validated the 'editor' template disappears and is replaced back with normal 'cell' template.

This has originated from 1.0 editing 'quick fix' and also because I was thinking that having input boxes or combo boxes in all rows always visible is simply not possible due to performance impact, so I can only afford showing one 'editor' at a time.

Now after seen several prototypes using beta2 it seems that many people would prefer having editors (like checkbox or combobox) always visible instead of just appearing when you switch the current cell into edit mode. So I added input template and combo template. And now there are two ways of doing the same thing and explaining and maintaining this is really confusing.

To fix this I am going to change the editing API - I will remove separate 'editor' template and if you want to make a particular column editable you would assign it a cell template which has editing capabilities built in (input, combo or checkbox). There will be also stylesheet classes which will define if the cell 'looks like editor' always or only when selected.

I rolled back cell editing from beta3 and will release beta3 later today without changes in cell editing. The new API will be implemented during the next two weeks and released as beta4.

This is a major breaking change so I would prefer to have some discussion whether I am doing the right thing this time.

It sounds good,
Just trowing ideas... Is it possible to include a "generic" Popup Template and not only for combo?

I mean, to avoid the restrictive use of AW controls/templates, and for cases where are not enough room inside a single-cell.
( i.e. images/calendars/other "no-aw controls")

Also a "basic" but customizable imput-template could be useful.
Thanks

Sounds good but since I've moved from v1 to v2 (either beta) I've had problems with scrollbars not appearing and "method not supported" script errors pointing back to line 32 in aw.js in some browsers on beta 2, a little worried, but I need the Safari support so do not want to go back to v1. Anything you could tell me about these errors would be greatly appreciated.

Dear Alex,

I think it is a good think that key users can discuss the orientation of technical features, and therefore I will raise my opinion, for what it's worth...

I have been testing all betas since their start and have also encountered the problem of one select box or a column full of select boxes, for example...

The problem is that controls are used differently : For example, it is ok not to display a select box in all lines cause the value is displayed already in the grid, so it is convenient enough to double click the cell, and then have the selectbox displayed.

On the contrary, a checkbox shall be (to my opinion) always displayed : You might use a checkbox at column 0 which allows to delete a row, and therefore the checkbox shall be visible for all lines, so as to get a simple overview of what will be deleted. According to me, this is the case for all kinds of use of the checkbox...

So I don't have a complete solution, but maybe the best thing to do is to have a mixed solution.

Furthermore, and with the respect that I ought to such developpers, I think that there should be a method (which maybe exists already, but I am not aware of it) that allows to set the data correctly :
If I get a line with a checkbox in column 1, the myData array would look like :
["false","text",...
OR
[false,"text",...

But then, first value is the text associated with the checkbox, and not the checkbox state. So Is there a way to do this already, or this is a good or bad idea that might help to have a complete developpment API.

Anyways, thanks for reading, thanks for your time, and as I also read the comments (good or bad) on pricing of AW, please know that a lot of people consider your grid as the best grid available, I went to check all the other links given by other users :I can't even compare one of these grids to AWv1, even less to v2...

Ready to see beta3!!!

Regards

As a broad generalisation I would say that grids are primarily for displaying data and that editing records is best done on separate forms. For example the application that I am developing shows dbase tables in the grid and then if contents of records need to be changed the user dbl clicks on the individual record and the record then appears in a separate form (different part of page, new page, pop-up or whatever). Having a separate form helps things like validation etc. When editing the record is finished the record is updated in the grid and the form cleared.

That is not to say that having an editable grid is not important; indeed, the form that I refer to above, in my case, is a one row grid comprising input, combo, checkboxes etc., but because it is only one row it can be made of 'always visible' AW control objects quite easily.

Also, as Alex indicates, I would agree that it is important for a grid (of many '000s rows potentially) to have some 'always visable' editable columns and the obvious example is a checkbox column, so that many records can be checked (for deletion, for example) at a time, say using a 'check all' checkbox in a header row. In fact I would like to see checkbox, combo and radio controls have the ability to work in this way.

Will

Another important question (I think)...
Would the new API include data-validation with lock/undo/alert capabilities?

I think the original approach you had was good.
I like the idea of having simple text as the default that changes to a combo box or some other control when you change it to edit mode. If you had all of the boxes in edit mode all of the time, users could inadventantly make a change to a value when they did not expect to. Furthermore, you can make it appear that all cells are editable by using the onFocus/onMouseOver events to change the cell to edit mode one at a time.
Most of my grids are not dialog type grids where you can make all of your changes and then click on a Save button. Most of my grids are multiuser and realtime where several users can be working on different rows, so when a user makes a change to a cell, that change gets updated to the database immediately.
Having said that, your approach seems very elegant as long as you still have the flexibility of choosing between editing always on or only on upon selection as you mentioned with the stylesheet. You need to be able to show checkboxes disabled unless in edit mode. Obviously, if there is a performance hit, it might be a different conversation.

Completely agree with carlos, maybe all of us now have a grid that allows to add rows, delete rows, correct sorting... so the first concern is to provide more controls, such as a dropdown editable textarea (cf Carlos examples in v1.0) for multiline texts... might add user functionnalities that makes it possible to do everything we need with AW...

If people don't know how to do the add/delete rows, let us take care of it in the forum, while you keep up the good work for us!

....more controls..... (more scope creep at the 11th hour!)

Version 2 of this toolkit is at Beta3!! A significant API refactor, adding more widgets to the pile....who knows what impact this work will have on the proposed production release date?? Unless there are tonnes of unit tests to quickly catch problems and get them fixed as quickly I suggest that adding major new features is a VERY bad idea....in my experience that is :)

Surely at this late stage ensuring a robust, well tested (almost) bug free piece of software is "the first concern" ?

Am I the only one who thinks this?

BT

I agree with BT at this point. It seems that there are still some basic issues that need to be resolved like add/edit/del rows with XML and displaying images (ImageText, Checkbox, Link, ... Templates) in a grid. Even though I know these are all inter-related to editing, it seems like taking one step at a time would be prudent.

BT,

yes, I agree, this is not healthy situation, this is why I am interested in your opinion. Just small correction, I am not adding new features/classes, the templates are already there since beta2 - I am going to remove duplicate method to achieve the similar behavior (namely setEditorTemplate).

Yes, this most likely break your code if you had implemented editing already and, yes, it will cause another 4-6 week slippage and push final release date into January.

We create the rules! Things become rules if majority of people agree to it and accept to follow in the future. It isn't anything bad if new things need to emerge instead of wasting time in fixing bugs THAT IS JUST GOING TO BE RE-WORKED ON. So, basically it isn't considered a new work rather a NEW RE-WORK. This is unavoidable in some cases and this time with the case of v2.0.

Alex,
> so I can only afford showing one 'editor' at a time

· That is the approach, there are few exceptions but. One is the 'CHECKBOX' which most people agree.

· The Best example (and the globally accepted one) is the Datagrid view of Microsoft Access. Users would be really please if you are ever able to do that. Here are the key points:

1. For Entries of type TEXTBOX, COMBO use EDIT-BY-DBL_CLICK method.
2. For Entries of type CHECKBOX use EDIT-WHILE-VIEWING method
3. [If Possible] Reflect the current row using a pointer beside the current row number (in the row selector)
4. [Enable/Disable Feature] To always display an empty row in the bottom (may be a footer can do the job) for inserting new row items onto the DataGrid, regarless of the sorting feature.
5. Provide APIs to focus on the first Cell of the footer row, providing the developer to use it for redirecting onclick events to a button such as "Insert New Row"
6. Provide events for input-validation when:
· a cell gets its value changed (cell onchange)
· a cell loses focus (cell onblur)
· a row loses focus (row onblur)

Using Popups for adding/editing rows actually consume more usability time and are actually considered work-arounds in places where inline-editing is not possible. In some cases, popups really prove useful when the number of columns in a row becomes pretty big.


I will do more analysis and come up with the missing ones if i ever find one.

Best Regards

Keep up the good work!!

I understand Alex, and think it was a good idea to request peoples opinions.

While we're on the subject of opinions... :)
I'm just wondering if you have a current prioritized bug and todo list (like in Bugzilla) and if so....maybe you could publish it and get feedback from people on what they really need fixed.
That way you could get statistics on what's most important for the next release and people out here can get an idea of what needs to be done to complete V2.

I just think it can be easy for people who are not in the loop to expect all their specific issues to be resolved immediately. Of course that's not always possible...everything has to be on a schedule.

That's just my 2 pence worth :)

BT

We are looking for the MS Access DataGrid view as discussed above. However, the one request I would like to make is that the actions be easy to override. We would like to pop into edit mode onClick, not onDoubleClick.

In addition to the DataGrid view from MS Access, the navigation upon editing could be like MS Excel. When you're editing the cell, and click on the arrow keys, it'd be nice to move out of the cell and immediately start editing the cell you just arrowed to.

In reply to Brad and Alex

Good one, seems very important to me too : in testing mode, I have to do doubleClick but shall be much more convenient for users on single click...
Arrow keys also important for functional use of the grid.

Oops, I think my previous post looks ambigous.

We create the rules! Things become rules if majority of people agree to it and accept to follow in the future. It isn't anything bad if new things need to emerge instead of wasting time in fixing bugs THAT IS JUST GOING TO BE RE-WORKED ON. So, basically it isn't considered a new work rather a NEW RE-WORK. This is unavoidable in some cases and this time with the case of v2.0.

Alex,
> so I can only afford showing one 'editor' at a time

I am no part of ActiveWidgets.. My first couple of sentences were the miskakes.. (WE - the IT people).. Sorry for any confusions I might have caused.. or ignore them if i had not done one.

All the description in my previous post were my suggestions ONLY!

Here One idea.
I did not look all of the information!
When i was ask 8 year ago to crate Virtual press some of the challenge was to update whitout refressing the page a tempo zone all of the form field with a miror, one in the grid case on row (id) in the tempo zone that zone is querry the database for update add or delete that row.

p.s.

activewidgets is realy the best solution for generic object orientation solution for the web

My thoughts on the editing is that if you have the grid set for editing, all cells use the 'standard' view control until a row is selected. At that time, cells for that selected row, that need edit capability, get the edit template. This way, there is only a template swap once a row is selected and you only need to swap the columns that have an edit template. So I guess that means that I think a column can be assinged both an edit and a view template.

Just my thoughts...

About controls :

Maybe the input type password shall also behave like checkboxes cause otherwise, it just displays the password as long as the input is not in edit mode...!!!

Comparing to excell 2003 behavior ... Excell works like this : to get the focus into a cell you need to click twice, like with the grid. However there is a difference, that is once a cell is selected in excell, you can type in to modify its content, actually to replace it, while with the grid you need to click twice, before typing and most often select the cell content to replace its content - at least 4 clicks total.

I would vote to implement the same behaviour as in excell because this tool makes the user experience reference.

Grid editing is extremely useful to my users, it allows to update a list of "tasks" in one screen!

I like to see a variant of a combo where the user is only able to select a value into a list - clicking into the cell would popup the list of choice.

Philippe Marzin

Grif Should Exactly work Like A JTable

josh

Please implement cell editing as closely as possible to Access or Excel, then state clearly what has been done and for expert developers, please explain clearly how to override the default, and please make overriding easy to do. Thank you, Tom
Text editing is really important.