Existing value not pre-selected in radio field when editing.

paulhickman

In version 1.2.3, I have a field defined as follows:

[code]
{
"label": "Enabled:",
"name": "Enabled",
"type": "radio",
"default": true,
"ipOpts": [
{ "label": "Enabled", "value": true },
{ "label": "Disabled", "value": false }
]
}
[/code]

If I examine my data in the chrome console with:

$("#mytable").dataTable().fnSettings().aoData[4]._aData

I get:

[code]
Object
Enabled: false
ID: 2008
Name: "Item 1"
__proto__: Object
[/code]

This shows that the Enabled property of the data rows is correctly set to either true or false as a boolean datatype, not a string, matching the values specified in the field definition.


When I edit a row, it displays the form with neither the Enabled or Disabled button pre-selected - i.e. ignores the value of the Enabled property in the data row. When I submit the form, it does correctly send the selected choice to the server and update the selected row of aoData in the underlying data table with either true or false.

If I then display the edit form for a 2nd row, it leaves selected whatever option was chosen the previous time the form was open.

Furthermore, if I load the page and click new, it does correctly pre-select "Enabled" as the default choice. If i then edit a row, select "Disabled" and submit that change to the server, then click new a 2nd time, this time it has "Disabled" pre-selected - it hasn't reverted to the default choice.

allan

Hi,

Sorry you are having problems with this. Unfortunately there isn't a quick fix for this problem - it arises because Editor attaches the values that the radio items can be to the DOM `value` attribute, rather than keeping them in pure Javascript. This effectively casts the values in `ipOpts` to strings, and since `true != 'true'` we run into this problem.

There are two ways I can see to address the problem:

1. Modify Editor to not use the `value` attribute, but rather to keep the value in a custom javascript property attached to the element. I'm a little reluctant to implement this change as the value attribute can be quite useful. Perhaps it should be retained and Editor operate on a custom Javascript variable that is also put in.

2. Use strings for everything...

I think I prefer the latter part of the first option. I will look into this further and get back to you.

Regards,
Allan

allan

I've just committed a fix for this issue. Could you drop me a PM with your e-mail address and I'll send you the latest dev package, or I can give you a diff if you prefer?

Allan

paulhickman

Allan,

Version 1.2.4 has fixed this for type=radio, but type=select has a similar issue.

allan

Yup - same issue - because the value is read from the HTML option tag's value attribute, it has to be a string. I could do something similar as was done with the select tag, but that feels _very_ messy to me. I'll have a think about this and get back to you.

Allan