You actually wouldn't need to set up the table. The way the sessions
framework works is that it returns info already set up in the
django_session. All you have to do is call some code that looks
something like this to save the session info:
if request.session['querysets']:
request.session['querysets'] += {'randomKey' = random number,
'querySet' = the query set } # obviously, "random number" and "the
query set" aren't actual code
else
request.session['querysets'] = [ {'randomKey' = random number,
'querySet' = the query set } ]
Django has the "request.session" dictionary set up so that it
automatically does the database processing behind the scenes. As for
why not auto-incrementing, it's because it would be much more complex
- if you use a random number (probably 1 to 65,535 would be better
than 1 to 1000), you don't have to look up previously existing numbers
to increment it. There's still a slight risk that you'd get your
querysets crossed, but it's still not very likely, and it's easier to
implement. And it doesn't really matter from a security standpoint -
if someone could get into your database anyway, it wouldn't matter
what kind of keys you had.
Regards,
Leaf
On Aug 31, 7:57 pm, Egon Esser <[EMAIL PROTECTED]> wrote:
> > First off, the server keeps session data, not the browser,
>
> Ah, great, learned something new!
>
> > but I understand what you're talking about. There's no real way without
> > extra programming to handle that, but here's a scheme that should be
> > fairly minimal:
>
> > (1) On the "Search Results" page, create a new list in the session
> > variable 'refineResultCommands' and put a dictionary in it with two
> > variables - randomKey and querySet. randomKey could just be a random
> > number between 1 and 1000.
> > (2) Use a form for the refinement. Have a hidden field that passes the
> > randomKey.
> > (3) On the refinement page, compare each stored randomKey with the
> > randomKey from the hidden field. If they match, display the refined
> > results. If no randomKeys match, then display a field that says
> > "Search first, then refine."
>
> An interesting concept!
>
> If I understood it correctly, then I would only need to setup a table
> in the database that remembers the respective previous query object
> (or alt.: list of search terms), with the randomKey being the key.
>
> Generally, though, why random? What sec hole would it open if the key
> where an auto-inc num, wrapping back to 0 or so at some point?
>
> EE
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
