On Fri, Nov 14, 2008 at 2:28 PM, Jonas Pfeil <jonaspf...@gmx.de> wrote: > > Just to be clear we are talking about the same thing: With "persistent > filters" I just mean "going back to the _filtered_ change list after > editing an item". I don't think it makes sense to make them any more > persistent :) Clicking on the link to the change list on the admin > home page should give a fresh start. > > On Nov 14, 2:15 am, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: >> Persistent filters makes sense; we should do that. But in the URL if at >> all possible, since it's best practice. > > The change list should really have an URL that includes the filters. > It's a different resource after all. I don't know if the "passing URLs > to a friend" argument is really fitting on the URL of the edit view of > an item though. If we use a from_url GET parameter that would take my > colleague back to _my_ filtered change list. I don't know if this > makes sense, but doesn't really hurt I suppose. Except that it may, > unintentionally, leak the information you searched for to another > person. If we don't want this we could put the information in the > session and use a hash. > > So maybe it's best to use GET parameters as before for the change > list, but store the from_url in the session under a hash that we set > as a GET parameter for the editing process. Just using the session > wouldn't cut it, as we need to track multiple edit actions in > parallel. > > Cheers, >
I've updated the existing patch created by slonopotamus for this ticket and intend to working on it hopefully making it worth considering for inclussion. I haven't, so far, changed anything fundamental, and wanted to ask for advice and opinions about the patch and in regard to what has been already discussed in this thread. First, I've found that the concern about the filtered changelist views in the admin app being addresssable resources only by using the query string are already covered by the current implementation so that part isn't something that needs to be solved ((am I wrong about this?) I've listed below a few notes about the patch, some of them with my questions attached: Currently, it: * Gets the URL where the the user should be taken back after the CRUD operation from the Referer HTTP request header, Is this a valid approach? Or should Jonas above ideas about storing it in the session be implemented instead? * It passes that URL around from view to view by using an query string value until the time to use it comes, it does so even when a POST request is sent (when editing or creating a model instance). Are we ok with this? * (Related to the previous item) The variable name used was 'admin_change_return_to', I've changed it to 'return_to'. Do we need to obfuscate somehow it to make it less prone to clash with other vars? * It uses the quote function from of urllib. Should django.contrib.admin.util.quote or django.util.http.urlquote be used instead? Thanks for any feedback. -- Ramiro Morales --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
