Whole Table Submit - Export to windowed table?
Whole Table Submit - Export to windowed table?
Hi All,
I've successfully created many data entry tables which have been well received and used over the last 4+ years. These tables have included both inline editing and multirow editing.
The one consistent critical feedback I've received is that the updating is convenient if you need to only update one or two values but if there are significant changes required to the data it can be quite tedious submitting each of the changes. Multi row editing was not helpful as the values were different for each record. We've used a work around to date where the users provide the updates to the admins who then load directly into the backend.
I've been toying with the idea of exporting the table to CSV and then allowing them to import the same table back in to capture the changes as a whole. There are a number of challenges to this, the main one being hidden row ID columns that I wouldn't want the users to mess with and also maintaining valid data with input restrictions such as list box selectors and date selectors.
Recently I've witnessed similar data entry tables but that allow the users to make the changes to the whole table before submitting. This would be significantly more efficient for the users. I'm not sure what the script/plugin was used for this but the effect was that the table appeared as though Excel replaced the table and allowed the users to make a number of changes before submitting.
Maybe I've missed something in the recent enhancements but does anyone have any ideas or examples as to holding the user entry changes and submitting as a whole?
Appreciate any feedback or ideas - I've enjoyed using datatables/editor over the years but this issue has my management looking at other solutions.
Thanks
Pete
Replies
Hi Pete,
Would something like this do what you are looking for?
Does this requirement arise from the Ajax request for the form submit being slow, or is there something else at play? Some form of UI interaction that is slowing things down? The one thing I worry about with a whole table submit is invalid data - if the validation is done at the server-side (which it must be regardless of client-side validation being present or not) and a row fails - feeding that back to the user when submitting the whole table can be awkward.
I did make a UI once for multi-row editing whereby you could edit the value for each row being editing, or group them all together. I found it really awkward to use in the end though...
Allan
Hi Allan,
Thanks for the reply. That seems to be very close to what would be a workable solution.
We currently already have multiple editor instances. We will generally have one for new records (entering a new employee requires a different interface due to fields that are non editable after creation and the new record creation calls a separate server side function), one for editing the entire row(s) and another for inline editing as these two editors call a different server side function.
Yes, the issue is that the table response while submitting a change takes 2-3 seconds and sometimes much longer if the user is accessing through a VPN
Local table updates would be a solution but I'd still like to keep the inline editing.
To resolve the submission failure could we compare the value submitted with the returned value? ie value was 8, changed to 10, submit, returned value is 8, highlight the value in red and flag as unsubmitted with a try again dialog box.
Thanks
Pete
I think a dialogue box would probably be a good solution. Client-side validation would probably catch "real" users mistakes (at the expense of the extra development needed for it), while the server-side validation would then catch anyone trying to hack around it and they aren't going to be bothered about the niceties of a user readable error!
Let me know how you get on with it
Allan