Well.... one way of looking at this is that HTTP is supposed to be stateless, and GET requests are more or less intended to return the same results for the same parameters - assuming the data hasn't changed. In this case, storing state in the URL is exactly the right thing to do. It's ugly, but it's fairly easy to do and works well with the browsers back button, search engines, bookmarks, copy & pasting URLs, etc. It might be helpful to have some utilities that rewrite URLs for you, but not necessary. It could also be helpful to still cache the query results and refer to them with either a search_id parameter or a combination of the search parameters so that you don't run the same query on the db for every page/object.
Another view is that with sessions and cookies HTTP hasn't been truly stateless for a long time., so you could save the search state in a session/cookie to avoid ugly URLs. That's the only positive I can see though. The negatives are that you can run into trouble with multiple windows or tabs, the back button or users saving or sending links. With those problems I tend to this that state in the URL is exactly the right way to go. The only con is ugly URLs, but when will the user even be typing a search into the location bar? AJAX has brought another solution which is to store state in JS and use an async request to do paging and details. The ugly URLs are hidden from the user and you don't have the problems of saving searches in the session. The problems here is that it takes away functionality from the user. They can't easily bookmark a query and the back button is broken unless you use a JS history manager. So I'd recommend ugly URLs. IMO the pros greatly outweigh the ugliness. One thing you can do is give nice URLs to pre-canned searches, like /search-name/page2/ Hope that helps, Justin On Fri, Mar 7, 2008 at 6:42 PM, efege <[EMAIL PROTECTED]> wrote: > > Hi, I'm new to Django and Python too, and just started planning the > migration of an existing app to Django, after reading (though not very > carefully) The Definitive Guide to Django. Excellent documentation, > BTW! > > I'd like to know which is the recommended approach to handle this > situation in Django -- though I'm not sure how Django-specific my > question is. > > A user does a search, the result is a paginated list of records, and > each record on the list has a link to a details page for that record. > Once in the details page, the user has these 3 navigation links: > > A. Go back to the list (i.e., to the same results page where the > current record appears, preserving list sort order) > B. Go to the details page for the previous record in the list > C. Go to the details page for the next record in the list > > Also, the user can stay on the current record, but changing its > display style among several available styles. Whatever the chosen > style, the above 3 links must be present. > > So the problem is: how do you keep the context (search query, and > record's position in results list), so that the above 3 links can be > generated from the details view/template? > > FYI, my app originally saved that context in the URL used to request a > details page, thus creating ugliness such as > > ...&task=display_record¤t=2&total=13&queryID=/tmp/filesbdfi4 > > to display the 2nd record in a list of 13 results, where 'current' is > the index of the current record in the list, 'total' is the length of > the list, and 'queryID' points to a temp file where the query results > are cached. > > Is the scenario I described common enough to have some known name? Can > the Django's session framework help me in this situation to keep the > URLs short and clean? What approach do you suggest? > > Thank you in advance for sending some light in this direction :-) > > --Fernando > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
