read-only fields on validation error

[tisdall]

Read-only fields are only displayed and aren't included on form submission. If a person submits a form with read-only elements those elements aren't included. If the form doesn't validate, then, deform.exception.ValidationFailure.render() doesn't contain the previous values for those read-only elements and then leaves it blank.

What's the typical way of handling this issue? It seems like it's not dealt with at http://deform2demo.repoze.org/readonly_argument/ (just try submitting the page there and all the values disappear)

Should we be including hidden fields with read-only elements purely for display usage?

[J20S]

I am having exactly the same problem.
One of the solutions to it is you can actaully declare missing value when you construct your schema node. (e.g. missing = str('')). However, the downside of this approach is when validation fails, the readonly field loses the value, which makes the interface looks confusing. When you submit again without validation errors, this field will be filled with your decalred missing value.

Hidden field is another solution, but from time to time we may need the field to be displayed. So this is a bit embarrasiing.

The other approach I used is to actually write a function which converts the post item list to appstruct when validation fails, so that we can still keep the data.

[Mr-F]

I have run into this problem and ended up creating a custom readonly widget (similar to what @J20S suggested).

My reasoning for this was that it would still allow me to present a "display" of the information without disclosing or polluting the HTML with hidden form elements when they were not needed. However, when a form element needed to be fixed/readonly, but still re-populate if the form wasn't validate then to render a hidden input along with the text output of the value.

[magoarcano]

With the last version of deform, with Bootstrap 3+ I can add HTML attributes to the field:
title = colander.SchemaNode(colander.String(), widget=TextInputWidget(attributes={'readonly': True}))

[digitalresistor]

@magoarcano your work-around is what the library should likely be doing rather than the current which just outputs the data in HTML.

[magoarcano]

@bertjwregeer You're right. In the way I proposed it works, there is no validation errors, the data doesn't disappear on Posting. But on the other hand user could hack the form and POST the data changing that readonly value. So validator code should be fixed then.

[stevepiercy]

The UI for the workaround is fine for TextInputWidgets, but it is horrible for selects, radios, and checkboxes. The user can click these elements and their changes may be saved. I think a more UI friendly method is to render the values as just plain text and insert a hidden input with the value of the form element.

[stevepiercy]

Upon further thought, we can set the checked/selected values as readonly, and the unchecked/unselected values as disabled, either through HTML or JavaScript. See https://stackoverflow.com/questions/1953017/why-cant-radio-buttons-be-readonly

[stevepiercy]

This issue will need documentation that distinguishes between readonly as a Deform widget option that renders only the value and no form controls, and an HTML5 field attribute.

[stevepiercy]

To display the un/selected values for checkboxes, use attributes={"onclick": "return false;"}. This gets rendered as onclick="return false;". This will go into the documentation.

[stevepiercy]

Single selects are similar to radios. Multiple selects however are problematic. I don't yet have a solution for plain old multiple selects because I can deselect selected options, submit the form, and the values are updated.

For Select2 multiple selects, we can lock selections or https://stackoverflow.com/a/24109346/2214933.

[stevepiercy]

Bad news. Plain old multiple selects do not allow locking of selected values. I might be able to do something with JavaScript, not sure yet. Select2 had the locked feature in 3.5.x, but was dropped in 4.0, and it looks like it will not get this feature back any time soon.

We might want to switch to another select widget.

• selectize.js appears to have the features we need, including locking.
• chosen is no longer maintained.
• react-select may be the future of we go that route.

[stevepiercy]

I think I will add selectize.js and not attempt to write custom JavaScript that locks the selected values in a multiple select input. I never use the default select when I use multiple values, preferring to use select2. selectize.js looks better all around, and just 10 days ago new maintainers jumped on board.

[stevepiercy]

In Deform 2.0.15, I plan to deprecate Select2Widget, and remove it in Deform 3.0.0. Its jQuery plugin Select2 removed a lock feature in v4.0.0 and its future development is questionable.

To replace it, I will add a new widget SelectizeWidget based on the jQuery plugin selectize.js. I'm very pleased with its features, and I have implemented a feature where passing in attributes={"readonly": "readonly"} into its widget will display the selected values, prevent the user from selecting or deselecting their values, and when submitted will redisplay the original values. Of course the server should still validate the input and never trust the user, but this is a great step forward for the UI.

If anyone has any objection to this plan, please speak now!

[stevepiercy]

Fixed and released in v.2.0.15.