Matt,
For 'temporary' state which does not need to live beyond an
interactive session with a website, I prefer to use a custom cookie
with an expiration of 12 hours or less.
Many times if it is just a CSS mark of some sort, I will just use 100%
javascript to get the job done, as it means I can even cache the page
being rendered for an added performance boost.
If it is something that needs to move with the user (i.e. they log
out, then log back in, or go to a different browser/machine), or cross
users, then a Model is the only maintainable way of doing it. I might
use the user session cookie, but ultimately it's data in the DB.
For really complex applications, I do both. Store the data in a custom
cookie, and if there is an associated user, then parse the cookie data
and also store it in the Database. If you go this route you need to
plan your data management carefully (merging issues for changing
cookies). That is how the PyCon scheduling app works. This means I can
cache the expensive to render times table, and let javascript to the
context highlighting. It also means that you don't need complex AJAX
talking back to the server to change state which increases server,
bandwidth, and time overhead.
http:://us.pycon.org/apps07/schedule/
-Doug
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
