Table 'overlay' for read-only behavior
Table 'overlay' for read-only behavior
![Jeach](https://secure.gravatar.com/avatar/4f6c8ef4a8064b286e0124519896e4dd/?default=https%3A%2F%2Fvanillicon.com%2F4f6c8ef4a8064b286e0124519896e4dd_200.png&rating=g&size=120)
I've seen a lot of questions/replies in regards to make rows read-only.
I've got a particular case where we show our data most of the time, but under some specific business rule, I must prevent the user from making any changes to table. I currently do this by adding a large gray overlay with 50% transparency over my panel. This works, but since the overlay is also over the header and footer, it does not allow the users to sort columns, filter data or more importantly navigate the paginated table (ie: next, prev, etc).
It would be much better if internally, data-tables would apply such overlay only on the view-pane of the data (optionally header). This way, the entire table content would become read-only, but still allow next, previous navigation.
I simulate the overlay by putting a div element spanning the entire size of my panel and setting its z-index to a higher level than it's parent. I'm sure this type of feature would easily be doable within the actual table itself and providing an API call for it.
Note: My tables are updated every second with new rows and row removals (quite dynamic) so the last thing I want to do is start to set a read-only state on a per-row basis (like I've seen so many examples of).
Feedback is welcome!
Thanks in advance,
Jeach!
I've got a particular case where we show our data most of the time, but under some specific business rule, I must prevent the user from making any changes to table. I currently do this by adding a large gray overlay with 50% transparency over my panel. This works, but since the overlay is also over the header and footer, it does not allow the users to sort columns, filter data or more importantly navigate the paginated table (ie: next, prev, etc).
It would be much better if internally, data-tables would apply such overlay only on the view-pane of the data (optionally header). This way, the entire table content would become read-only, but still allow next, previous navigation.
I simulate the overlay by putting a div element spanning the entire size of my panel and setting its z-index to a higher level than it's parent. I'm sure this type of feature would easily be doable within the actual table itself and providing an API call for it.
Note: My tables are updated every second with new rows and row removals (quite dynamic) so the last thing I want to do is start to set a read-only state on a per-row basis (like I've seen so many examples of).
Feedback is welcome!
Thanks in advance,
Jeach!
This discussion has been closed.
Replies
I don't really understand I'm afraid. What about the rows is read / write? You would need to use additional software beyond DataTables core to make the rows read / write (jEditable, Editor etc for example).
Allan
Some columns, have icons which when clicked on, allows the user to possibly delete such row or edit the row (in another web page) or reset a state of such row, etc.
This all works perfectly! But on a specific condition (which comes from the server), the user should no longer be allowed to manipulate the rows (or press such icons in specific columns). I simulate this by adding a huge overlay (ie: a 'div' glasspane, if you will) over the entirety of the table.
But like I mentioned above, this also masks the header and navigation footer and prevents the users from navigating.
If I could 'only' put such glass-pane overlay on the table-view it would be a lot more user friendly. This would prevent such column icons from being clicked on and thus simulating a read-only table.
I hope this clarification helps.
Failing that, why does your glass pane need to cover the whole table? Can it now just cover the tbody section?
Allan
Although I respectfully disagree with your analysis that disabling total interactivity with a table should be delegated to a higher level (ie: application). In the past I have seen so many times where this general feature was needed (other companies, other projects). And I fail to see why it wouldn't be needed by a large majority of projects.
Just to add a correction, I don't disallow the editing environment while there is an update in progress. I wanted to avoid specific business logic and business rules, but if it will clarify my example I will... so here goes:
Our web application has built in redundancy by means of having a backup server. When the user navigates, all application data-feeds and user interaction is made from the 'primary' server. The user can (optionally) navigate the backup server and when he does, no user actions (ie: delete rows, reset calculations, edit cell entries, etc) can be made on such data tables (thus the glass pane preventing it). Only when the primary falls, does the backup become fully operational within a few milliseconds (after a sync with the primary) and the table glasspane gets removed where any user interaction with the table is then allowed.
This all works great, except that since my glasspane is over the entire table (on a panel), the user can not use the 'next' and 'previous' navigation links (described in first post) on the backup while it is in 'backup-only' role.
Should such glasspane be applied ONLY to the view-port of the table, then all navigation, filtering and column functionality would still work (but not actions and edits).
I'm 100% confident that attempting to disable the entirety of a table is not limited to a small number of projects.
As for your question: "Can it now just cover the tbody section?" I'm not familiar with the low-level architecture of the DataTables, but assuming that a table uses only one 'tbody' per table and has a unique ID or a specific 'class' attached to it (so I can use jQuery to interact with it), then instead of applying my glasspane on the panel, yes I should be able to simply attach the glasspane on the 'tbody' element instead (somehow, I guess). I will experiment with it. But then again, if this works, I don't see why it couldn't become par of the underlying functionality of DataTable?
Thanks,
Christian
Allan
Allan