Skip to content
This repository has been archived by the owner on Jan 1, 2020. It is now read-only.

Dates are not reformating after editing #43

Open
bouks opened this issue Jan 12, 2015 · 11 comments
Open

Dates are not reformating after editing #43

bouks opened this issue Jan 12, 2015 · 11 comments
Milestone

Comments

@bouks
Copy link
Contributor

bouks commented Jan 12, 2015

When inline editing dates are not reformated after saving or cancelling.

This is because "reformatAfterEdit" is set to false.

Why is it set to false ?

@meh-uk meh-uk added this to the 1.0 milestone Jan 12, 2015
@OlegKi
Copy link
Contributor

OlegKi commented Jan 16, 2015

It's good question, but I can provide examples which shows that it's really common problem in jqGrid. By the way cell editing works not in the same way like inline/form editing.

One more problem exist in case of usage "local" datatype with data. If you had for example Boolean true and false in the input data and makes local modification of the data you will have "Yes" and "No" strings assigned to the properties.

@bouks
Copy link
Contributor Author

bouks commented Jan 23, 2015

@OlegKi Can you tell us examples "which shows that it's really common problem in jqGrid" ?

I must inform all that date option format "j" for day formatting (in newformat option) is not working anymore with reformat after edit. It's now cutting the first number of the day (like 21 become 1) ...

@flack
Copy link
Contributor

flack commented Jan 23, 2015

@bouks Can you commit a demo which exhibits the problem?

@flack
Copy link
Contributor

flack commented Jan 23, 2015

BTW: I like the button logic that you have in the remote demo. I'm thinking if we should add more interactive elements to the demos to showcase API calls as well as config

@bouks
Copy link
Contributor Author

bouks commented Jan 23, 2015

@flack

With reformatAfterEdit : false
http://ribouka.com/test-date-reformat-false/

With reformatAfterEdit : true
http://ribouka.com/test-date-reformat-true/

Note the date day is defined on "j" then you can see the second bug in true test. But it is minor bug, since i can change to "d".

You can also see the bug fixed by :
https://github.com/bouks/grid.js/commit/102b9c6f02b48f6d9fd04907c06efdce11e117e2

@bouks
Copy link
Contributor Author

bouks commented Jan 23, 2015

I made a mistake about the "j" option bug, it does not "It's now cutting the first number of the day (like 21 become 1) "

It does : "Set the day to 1"

@OlegKi
Copy link
Contributor

OlegKi commented Jan 23, 2015

@bouks : Probably you have seen my last post and your question should be interpreted in the context of the changes.

To understand the problems I prepared the demo
http://www.ok-soft-gmbh.com/jqGrid/OK/dateEditing/editingTest.htm
it uses my current version of jqGrid. You can test all three editing mode: form editing, inline editing and form editing. It's important that inline editing and cell editing saves the current row in the internal parameter savedRow and restore the data on pressing Esc or Clickeing on "Cancel" button (in case of inline editing). The demo uses reformatAfterEdit: true. I'll remove the option (probably today) and all will work in the same way as in the demo.

The problem with reformatAfterEdit option is common for jqGrid. It's a property of column of colModel. So it should have the same effect in all editing modes, but the reality is different.

The demos
http://www.ok-soft-gmbh.com/jqGrid/OK/dateEditing/editingTest47-reformatAfterEdit-true.htm
http://www.ok-soft-gmbh.com/jqGrid/OK/dateEditing/editingTest47-reformatAfterEdit-false.htm
can be used to test the behavior of reformatAfterEdit: true and reformatAfterEdit: false in different editing modes.

editingTest47-reformatAfterEdit-true.html:

  1. You can click on any date and then press Esc to cancel editing. You will see: "NaN-undefined-NaN" instead of the date. If you click on any date, then edit it and press Enter to save you will see the same "NaN-undefined-NaN" results. So one can't edit jqGrid using cell editing in case of having reformatAfterEdit:true.
  2. Try to edit the row using inline editing or form editing. You will see that it works correctly. On the other side you can try to use first "+" button (Add by form editing) or the second "+" (Add by inline editing). You will get the same "NaN-undefined-NaN" value by form editing, but Add by inline editing will work.
    So reformatAfterEdit:true works correctly only in inline editing mode.

Now try
editingTest47-reformatAfterEdit-true.html:

  1. You will see that cell editing works correctly.
  2. After inline editing (add new row or edit an existing one) displays wrong data in the grid (in format 2015-01-23), but it one road the grid then one can see that it saves correct data in local data.
  3. Editing existing row in form editing displays also wrong data, but saves correct data, but adding new line follows displaying "NaN-undefined-NaN" which stay the same after local reloading. So Add operation of form editing display wrong data and save locally also wrong data.
    So reformatAfterEdit:false works correctly only in cell editing mode.

In other word one can say that no value of reformatAfterEdit solves all problems of local data editing. The value should be independent from any editing mode, but reformatAfterEdit:true works correctly only for inline editing and reformatAfterEdit:true works correctly only for cell editing. No mode is good for form editing.

It's what I mean when I wrote that editing of date "it's really common problem in jqGrid".

@OlegKi
Copy link
Contributor

OlegKi commented Jan 23, 2015

If you would try to use formatter: "number" or formatter: "currency" together with any editing mode together with German locale for example where , (comma) will be used as the decimal separator (decimalSeparator) you will see that the problem exists not only in case of usage formatter:"date". It have sense to edit formatted data in locale format and to save it back in unformatted form. jqGrid currently force everybody to edit 123,35 € as 123.35 value which is not good.

@meh-uk
Copy link
Contributor

meh-uk commented Mar 4, 2015

OK what's the status of this issue?

@bouks
Copy link
Contributor Author

bouks commented Mar 4, 2015

Sorry, i'm little busy these times. I think nothing has changed. I'll look at this when i'll come back if no one fix it.

@renanaraujo
Copy link

reformatAfterEdit with default value false does not make sense in my opinion, should be changed to reformatAfterEdit: true as default

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants