4 ms·
This is what sessions are for, maintaining volatile state that may or may not be written to a more permanent storage. If your application stack does not have a
by olefoo 18y ago
This is what sessions are for, maintaining volatile state that may or may not be written to a more permanent storage.
If your application stack does not have a session implementation that 'Just Works!'(tm) for you, you will have to implement one yourself.
Generally it will look something like a cross between your solutions 1 and 3, you create an opaque session key which is stored as a cookie and is used to retrieve the data from the session store. What you use to store session data is going to vary depending on how valuable the data and on how tragic failure is.
Avoid hidden fields in the html, they are a pain to maintain and will cause you problems because the temptation is to trust that their contents are what you put into them... it also means that you are repeatedly processing the same data. In sum; hidden form values make baby jesus cry.
- amrithk 18y agoThanks. It seemed to me in the beginning that HIDDEN fields were a very clumsy solution. Now I understand why they indeed are. We use PHP as our server side scripting language. I was thinking of using the $_SESSION variable but attributes and pointer information for 30 image uploads per user * no of concurrent users seems like a huge drag on server memory. I'll probably just write the pointer information to the database for now after each upload. It might make the web app slower by a few milliseconds but it reduces unnecessary complications
- olefoo 18y agoPHP uses files for storing sessions; you do want to restrict where on your site you are using sessions as they do have side-effects. Most notably any page served in a path configured for sessions will have an expiry time in the past and a bunch of no-cache headers; for a dynamic page that is the behaviour you want, make sure it's not being applied where it should not be.