Why are hidden fields used?

Question

I have always seen a lot of hidden fields used in web applications. I have worked with code which is written to use a lot of hidden fields and the data values from the visible fields sent back and forth to them. Though I fail to understand why the hidden fields are used. I can almost always think of ways to resolve the same problem without the use of hidden fields. How do hidden fields help in design?

Can anyone tell me what exactly is the advantage that hidden fields provide? Why are hidden fields used?

Answer 1

Most typical use I see/use is for IDs and other things that really don't need to be on the page for any other reason than its needed at some point to be sent back to the server.

-edit, should've included more detail-

say for instance you have some object you want to update -- the UI sends back a collection of values and the server at that point may or may not know "hey this is a customer object" so you fire off a request to the server and say "hey, give me ID 7" and now you have your customer object as the system knows it. The updates are applied, validated, whatever and now your UI gets the completed result.

I guess a good excuse/argument is using linq. Try to update an object in linq without getting it from the DB first. It has no real idea that it's something it can keep track of until you get the full object.

Answer 2

They are generally used to store state as an interaction progresses. Cookies could be used instead, but some people disable them. Could also use a single hidden field to point at server-side state, but then there are session-stickiness issues.

Answer 3

There are many useful scenarios.

One is to "store" some data on a page which should not be entered by a user. For example, store the user ID when generate a page, then this value will be auto-submitted with the form back to the server.

One other scenario is security. Add some hidden token to the page and check its existence on the server. This will help identify whether a form was submitted via the browser or by some bot which just posted to some url on your site.

Answer 4

Suppose you want to edit an object. Now it's helpful to put the ID into a hidden field. Of course, you must never rely on that value (i.e. make sure the user has appropriate rights upon insert/update).

Still, this is a very convenient solution. Showing the ID in a visible field (e.g. read-only text box) is possible, but irritating to the user.

Storing the ID in a session / cookie is prohibitive, because it disallows multiple opened edit windows at the same time and imposes lifetime restrictions (session timeout leads to a broken edit operation, very annoying).

Using the URL is possible, but breaks design rules, i.e. use POST when modifying data. Also, since it is visible to the user it creates uglier URLs.

Answer 5

Hidden fields is just the easiest way, that is why they are used quite a bit.

Alternatives:

• storing data in a session server-side (with sessionid cookie)
• storing data in a transaction server-side (with transaction id as the single hidden field)
• using URL path instead of hidden field query parameters where applicable

Main concerns:

• the value of the hidden field cannot be trusted to not be tampered with from page to page (as opposed to server-side storage)
• big data needs to be posted every time, could be a problem, and is not possible for some data (for example uploaded images)

Main advantages:

• no sticky sessions that spill between pages and multiple browser windows
• no server-side cleanup necessary (for expired data)
• accessible to client-side scripts

Answer 6

It keeps things out of the URL (as in the querystring) so it keeps that clean. It also keeps things out of Session that may not necessarily need to be in there.

Other than that, I can't think of too many other benefits.

Answer 7

heres one reason, convenient way of passing data between client code (javascript) and server side.