Editor - Possible bug / not consistent behavior in createInline

Red Sniper

Link to test case: http://live.datatables.net/veqeliro/1/edit

Description of problem:
The code in the test case is similar to the basic initialization page of the Editor docs.
I have added the "className" property to some rows of the datatable configuration.

I noticed that an issue may arise when you initialize an empty datatable and want to add a row with createInline.
Inafct, when the row with its inputs is displayed, it misses the classes specified in columns.className property.
But, If you use the createInline when the datatable already has some rows , the columns.className properties are added to the td element.

In my case, this generates errors, because I use some classes of the columns.className to perform some actions on the textContent (eg.) of the row that is being added by the user.

I can provide link to internal dev environment in private.

Thanks for the help
Davide

allan

Hi Davide,

Inline editing is only suitable for cases where a cell will map directly to a single data point. The example you linked to doesn't allow the first column to become editable since it is a "rendered" column (made up of two data points). The only way to edit such data inline would be to have it split into two different columns.

I see your point about the column class names not being used though. This is an omission in Editor and I'll get that fixed - thanks!

Allan

Red Sniper

Hi Allan,

Many thanks for considering the fix!
I understand your point. Unfortunately I have to replicate some tables i use in my desktop counterpart version of the software, and this was the only way (I guess). (I use the submitComplete to adjust the data before insert, and textContent for those cell who cannot be edited). But , anyway, it works!

Thanks for the help ! Really like how you are developing this library!
Let me know when you will be releasing the fix
Best regards

allan

Shouldn't be too far away - later in June I expect

Allan

Red Sniper

Great to hear!

I have noticed another possible bug , help me understand if it is one and if I should open a new discussion or not.

Simply talking, if you use createInline() to add a new row, editor.mode() changes to "create". But if you press "Esc" or programmatically close the row witheditor.close() , editor.mode() is not being reset to null

Since I cannot edit the mode manually i had to write some code for this situations (a user may exit the createInline() and use a button to update a row , without clicking on the row's editable cell so to refresh the editor.mode() . This way the actions I perform may not be the correct ones)

The test case is still applicable for this case too (enter the edit modal, press Esc and console log the editor.mode() )

colin

Yep, I'd say that's a bug - as the docs for mode() say, it should be null if no active state. I've raised it internally (DD-2565 for my reference) and we'll report back here when there's an update.

As a workaround, you could use display() to see if the form is currently open - that does pretty much the same thing (but does displays false if nothing being edited),

Cheers,

Colin

allan

Its actually a little more nuanced than that. The editing mode will actually remain active even when you close the end user visible form. This is to allow API actions on the data. Possibly I should disallow that when the form has been displayed, but that the moment, you could show the user the form, them close it and then you submit it. That works in all editing modes for Editor, not just inline create.

For the moment, do as Colin suggests and use display() if your logic depends on the form being displayed. If I were to make a change for this, then it would be a major release since the API behaviour would be changing.

Allan

Red Sniper

Hello there,

thanks to both of you !
For Allan, yes my logic depends on the form being displayed, so no problem in applying colin's answer . If it should cause major changes to the Api behaviour, I'd say that it should be fine for me to rely on the display() .

I will do some tests this week and let you know asap

thanks again
Davide

Red Sniper

Hello Allan,

I made some tests and updated my code accordingly.
Now I check both editor.mode() and editor.display() to perform the correct actions in my environment, and it seems to work fine ( this should avoid you modifying the api )
Should further tests show it is not , I'll tell you

In the meanwhile, thanks again both of you!
Have a nice day
Davide