Form serializing and ignoring disabled fields

[kstubs]

What is the thinking behind ignoring those fields items in a form that have been disabled?  Is this an HTML recommended standard?  

Here is what I do, perhaps there is a much better solution.

I often need to show a client a field value, like a primary key ID, but they shouldn't change it, so I disable this input.  I do like the look of the disabled input, and this is why I default to this view - but - the item is ignored on serialization.

Karl..

[Walter Lee Davis]

I can't speak to the original design intent, but it's probably related
to the way that Rails handles form submissions. Recall that Prototype
tumbled out of the same application design process as Rails, so it
shares some of the same design thinking (and quite a lot of language,
too).

If you are updating an existing object in Rails, you post to that
object (well, PUT, but hidden inside a POST) and therefore the current
state of any property of that object that you didn't include in your
post is already known, so anything you *don't* send just stays the
same, and all your changes are updated when that object is next saved.
Rails handles this through the routing mechanism, so a PUT (hidden in
a POST) to users/123 updates User#id = 123. My guess here is that if
you've gone to the trouble to disable an attribute when you show it to
the user in a form, you really aren't seriously going to consider
anything sent back by that form in any of those disabled attributes.
It's a further layer of security along the lines of Trust Nothing The
User Sends You.

If you want to show the ID to the user (for example) and you also need
to use that property within your application in order to key the form
submission to a server object, you could double-up with a hidden
element containing that data, like this:

<input type="text" disabled="disabled" name="visible_id" value="123" />
<input type="hidden" name="id" value="123" />

Rails just uses the URL for the same purpose, in keeping with the REST
methodology baked in at the platform level.

Walter

> --
> You received this message because you are subscribed to the Google
> Groups "Prototype & script.aculo.us" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/prototype-scriptaculous/-/YLypughOWWIJ
> .
> To post to this group, send email to prototype-s...@googlegroups.com
> .
> To unsubscribe from this group, send email to prototype-scripta...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en
> .

[T.J. Crowder]

Hi

> What is the thinking behind ignoring those fields items in a form that have
> been disabled?  Is this an HTML recommended standard?  

Browsers don't submit disabled fields, so Prototype doesn't serialize
them. This has been true pretty much forever, but here's the latest
HTML spec's description of this:
http://www.w3.org/TR/html5/association-of-controls-and-forms.html#constructing-form-data-set

So not just recommended, but dictated by the standard.

HTH,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

[kstubs]

Thanks for the follow up on this.  I've just recreated the "locked" value in a div element and have styled it to look well enough along side other inputs - this was all I was trying to avoid was about 3 extra lines of styling.

Good that Prototype is following standards.

Karl..