This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
You can use it to send values hidden from the user (i.e. no input box displayed). I use this for one application to send operation names from the client to a server which the Servlet will read and execute, and read other parameters if necessary. I wouldn't want this displayed in an input box, so making it hidden is useful.
Also keep in mind that if you are using hidden fields for session tracking you should take care not to hold any sensitive data in hidden fields since we can view the values held by the hidden fields by actually viewing the source of the html page. - John
Do not let what you cannot do interfere with what you can do !!<br /> <br />SCJP & SCWCD 1.4
We have two mechanism for session tracking, they are cookies and URL rewriting, the latest for the people that doesn't have cookies enabled in their browsers, I could only understand sending a session id in a hidden field when you have your own session tracker and are not using the one that is already with your server container (HttpSession and all), but why re-invent the wheel?
Hidden fields are for passing information between pages, sometimes I use a <input type="hidden" name="action" value="XXX"> and I clearly don't want that information displayed to the user
Have you ever seen the movie Finding Nemo? When using hidden form fields to store session (or conversational) state, it's kind of like your server is Dory (the fish with no long-term memory). Everytime you talk to the server again, you have to re-introduce yourself and remind it of what you've spoken with it about in the past, by passing it all of that information in the hidden form fields. This does take some of the memory burden off of the server. However, it can be tough to make sure you're actually writing all of the necessary hidden form fields (and their appropriate values) back to the client for use in the next request.
James Carman, President<br />Carman Consulting, Inc.
Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>
According to my experiences, that hidden fields are used to store values that is not displayed to users (such as using text field). Especially for storing the id of record is being displayed and the mode of process (such as ADD or UPDATE).
Here is a quote from my Internet Architecture page. The page very briefly discusses the pros & cons of each. See if it gives you some useful ideas ...
"Web applications often have to hold some information about the user for the time the user is browsing the site, say a shopping cart with several items in it. Designers have many choices about where to put such data. Here are a few:
[ February 10, 2005: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com