Replies

• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  October 2012

  > 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 Posts: 5Questions: 0Answers: 0

  October 2012

  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 Posts: 61,972Questions: 1Answers: 10,160 Site admin

  October 2012

  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 Posts: 5Questions: 0Answers: 0

  October 2012

  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 Posts: 61,972Questions: 1Answers: 10,160 Site admin

  October 2012

  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 Posts: 1Questions: 0Answers: 0

  May 2013 edited May 2013

  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 Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 2013

  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