Session Variables vs. Hidden Inputs

I often see people asking about how to make data persist across multiple pages of forms, and the two options that inevitably come up are using session variables and using hidden form inputs. Using session variable refers to the practice of saving your form variables as session variables, then accessing them all at once from the session scope at the appropriate time. Using hidden input refers to the practice of accumulating data from previous form in hidden inputs so that it looks to your action page or component that the user just submitted one big form (which, in fact, they technically did).

There’s nothing wrong with using hidden inputs, but using session variables is really the better solution. For one thing, it makes the code more versatile and gives you the flexibility to make your application less linear if you want to, or to more easily rearrange your forms. Additionally, the code is much more maintainable and easier to follow.

Some people use the argument of memory usage to suggest that hidden inputs are better since session variables are stored in your server’s RAM. Unless you are running ColdFusion off an Apple Newton, RAM is not going to be an issue. Let’s prove the point by doing the numbers:


Let’s say that a fully filled out form is about 500 bytes of data, or to make the math a little cleaner, let’s say 512 bytes, which means that for every kilobyte of RAM allocated to your JVM, you can handle two simultaneous sessions. That means to use a single megabyte of RAM, you would have to have 2048 simultaneous sessions. Admittedly, session data structures themselves (Hashtables) use RAM, so we’re not just talking about the bytes of form data, but considering the fact that I have 512MB of RAM allocated to the JVM on my production server, I don’t worry much about these details.If you are concerned about RAM — if your application use huge sessions and your servers are 10 years old with tiny amounts of memory — just buy another stick of RAM. In the long run (and maybe even the short run), it will be much cheaper than avoiding session variables.

12 Responses to Session Variables vs. Hidden Inputs

  1. Tarantor says:

    I think WDDX is a better way of doing this but I also used lots of time this method. But I also want to suggest to use structure for variables while using within sessions.Such as “session.myapp.registerform.username”, “session.myapp.registerform.name” etc.That helps a lot 🙂

  2. Steve Ray says:

    I don’t know if CFMX handles session variables differently than CF5 and before, but I have seen those things grind a server almost to a halt (on 4.5 / 5).I *always* advocate using WDDX’d client vars over session. You can store the same structures in them as you can in session without the RAM issue.If the JVM makes that much of a difference where this is concerned, I’d love to know about it.

  3. Client variables either hit the database or use cookies. The former is slow (in comparison to memory variables). The latter transmits a lot of data back and forth over the wire. Both cases – using WDDX – cause a lot of serialization and deserialization.Session data does not suffer any of those problems.I continue to be surprised by how many CFers use client variables instead of session variables. Even Ben Forta, at BACFUG the other night, was recommending session variables over client variables (and, in particular, J2EE session variables in CFMX).

  4. Andy says:

    As Tarantor above mentions it’s useful to put your sessions in a structure format rather than just hanging them off the main ‘session’. It also means that if you are worried about RAM, once you’ve submitted your form, you can kill those session variables by clearing the session.structure rather than just session

  5. William Dent says:

    In addition you can only use session and application variables to store persistant CFCs. Client variables will not work with CFCs.

  6. dgibson says:

    Let’s go back to why hidden form fields are NOT a good idea. If the integrity of your data is any concern, do not use form fields. This really depends on the application, but somehow I doubt most people revalidate all of the input at the end of a multi-page form submission.Form data can be manipulated via the DOM and is not secure. I learned this the hard way on my first shopping cart app years ago and even Verisign’s own “secure” shopping cart had the same faults a few years ago.

  7. dgibson says:

    and by “form fields” I mean in the context of the topic – passing values along between pages in multi-page form processes.

  8. illovich says:

    Is there a tutorial anywhere on how to do a multi-page form with Cold Fusion? I’m willing to use any method, including session variables. I just can’t figure out how to set it up.<————newb

  9. iis session says:

    To loop through a form:at the top of a page decide if a formvariable that should exist actually doesexist.if it does not, then do no processingexcept for form presentationif it does, then process form,possibly outputing form again,or another form altogether.this way the target of the submitis always the url that produced theform to begin with.as long as your processing presentsthe correct form for the circumstancesyou can just keep looping through++++

  10. How does using session vars make it more secure? I don’t see how its better than using just hidden form elements.

  11. Jose Alfonso says:

    What about sessions timing out?!!!I agree about using session vars instead of hidden fields (especially if you don’t want the user to see the data via “view source” even if in wddx format) but i’ve been burned with short time outs in servers and people loosing the variables when they leave their machines on for a long time.How do you guys deal with the potential timeout issue?Would client vars or cookies be best in that situation?

  12. About security, the hidden parameters could be seen from the source code. session variables are not viewable. So, if you only use hidden parameters someone can see what you are sending to the next page and make an program that sends to your next page his desired data. By that way he can make a bot or whatever. If you use session variables, use can always check whats going on.. 🙂