I believe the general best practice is that sessions should be viewed as a last resort for storing data.
You can store data in a number of places and they each have their benefits and drawbacks. The easiest place to store data is the URL, but storing user-specific information in the URL is a huge security risk and also tends to result in huge (and ugly) URLs. So this obviously isn't suitable for storing form state (especially things like payment processing forms). The second place might think to store data is in the session, there is nothing strictly wrong with this approach but you have to be careful about how you'd do it. You wouldn't store a user object in the session but rather the user id for retrieval from the database. The session is useful but you don't want it to be too big otherwise you incur serialization/deserialization overhead which is especially risky in clustered server environments. In the case of multi-stage forms the best place (in most cases) to store data between stages is in hidden fields that get POSTed with each stage submission, this completely alleviates any session overhead and can even let you go forward and backward between stages (assuming the implementation allows it, i'm not sure if the FormWizard stuff lets you go backwards). You do reach potential problems however if you want the user to be able to leave the form and return to it later and continue from where they left are. The solution in this case would be to use the session (or you could write the state to the database if you want them to be able to retrieve the state even after sessions have expired, but I'd consider this the very last option), when you do have to use a session for this (i'm thinking things like e-commerce order processes) you want to be careful to ensure that the objects involved aren't too deep (you don't want to blindly serialize a shopping basket which would in turn serialize all the products in the basket and then all the categories for those products etc), and you also want to ensure that you take any security measures in the format of the session that you would be taking in the storage of the final result of the form submission (ie encrypted credit card numbers). The line is always a bit fuzzy, but basically store state in hidden fields as a first resort unless you really need to allow the user to leave the form in which case store state in a carefully considered session object. - Andrew Grupo Django wrote: > Hi! Just a simple question. > The Form Wizard application stores the data hashed in hidden fields. > Why not in a session? Why is it better? I just want to learn best > practices. > > Thank you. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
