Would preserving filters open the door to also preserving the current
ordering and current page number in the admin view? I would suspect
that if you're saving one, you'd really want to save all three,
because they all go together insofar as returning you to *exactly* the
view you were last using. If you're going to preserve it at all,
might as well do it right and preserve it as pristinely as possible.
This last point is exactly why putting it in the URL is the better
solution. It's the whole idea behind addressable resources. You can then
pass around the right filtered view to a colleague via email for further
work. Or you can record it in an issue tracker. Or bookmark it to come
back to later on.
Storing it in the session would throw away all those benefits. We're
developing for the web here; let's use the advantages of the medium,
rather than doing all the work and then only making it available to the
single person viewing it at that moment.
Persistent filters makes sense; we should do that. But in the URL if at
all possible, since it's best practice.
Regards,
Malcolm
Yes, from the admin home page it should be a clean view. But that's not
the only way to access the change list. You can got there directly since
the web (and Django) uses addressable resources and the change list page
is a resource in that respect. Filtered views of the change list are
also resources and should have their own addresses, since they're
different from the unfiltered view. In that fashion, returning to the
filtered view from the add/change page and from a bookmark, email or
other means are all possible. Simple solutions tend to stand out like
that: they solve multiple problems at once.
There's simply no reason to say that the *only* way to get directly to a
filtered few is from add/change. That's a restriction without cause.
Regards,
Malcolm
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