Table 'overlay' for read-only behavior

Jeach

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!

allan

> I've seen a lot of questions/replies in regards to make rows read-only.

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

Jeach

Our tables consists of many rows, which get updated data every second from our server.

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.

allan

Thanks for the explanation. This doesn't sound, therefore, like something that DataTables core should provide, since its an interaction with your layer above DataTables, but rather something that the editing application on top of it should provide. Can't you just have a flag which will disallow the editing environment from taking any actions while there is an update in progress rather than pulling a blocking element above it (which wouldn't prevent keyboard interaction anyway, if your application allows for that).

Failing that, why does your glass pane need to cover the whole table? Can it now just cover the tbody section?

Allan

Jeach

Thanks for the reply Allan, I appreciate your time!

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

I see, so what you ideally want is something like `table.enable()` and `table.disabled()` to allow and disallow under interaction with all of the added controls (paging, sorting, filtering etc). Sounds like a good idea - its the first time I've come across this request, but I do like it. I doubt I'll be able to get it into 1.10, but it is now on my feature list :-)

Allan

headwinds

did this get implemented or is it still in the backlog? I could block the events but I like the simplicity of your suggested update...

allan

Yup - still on the backlog. I've only just got to the point where I think the 1.10 API is more or less complete, and these two haven't made it in (worried about library size). They make a very good option for a plug-in though.

Allan