On Feb 10, 1:43 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Ignoring portions of a URL sounds pretty broken. Our goal isn't to be
> like other frameworks. It's to behave correctly, in accordance with best
> practices for things like URL construction and consumption. I would be a
> little unhappy with 'ignoring' being something that happened there.
I agree, but I think it's a little more complicated. The basic
question is what should we do if an unknown parameter is passed to our
request. In the other parts of the admin interface that I poked around
in, the answer is nothing happens. If I put ?foo=bar on the URL it's
simply ignored. For the majority of views this is probably true--I
think that code uses the parameters it needs or expects and ignores
the rest. The exception is the change_list view, because it doesn't
have a fixed list of parameters and tries to consume them all as a
filter. So the change_list is actually an exception to the rule. In
fact, rather than silently ignoring unknown parameters, code was added
to throw away the entire request and redirect to ?e=1 when an invalid
filter was passed. This was done to prevent the admin from causing an
exception on a bad filter.
With the new filterspecs, we have the possibility to put arbitrary
parameters in our request that can be consumed by any filterspec. In
André's patch, each filterspec has to have a function to consume the
parameters that it's going to use and the remaining parameters are
checked as before. My thought was that we have a lot of extra code to
check that we are using every parameter and they are valid. If we
simply ignored parameters that didn't filter or weren't consumed by
filterspecs we would make it simpler to write an inherited filterspec
without having to consume the parameters it's using and we could
eliminate the strange forwarding to ?e=1 behavior while still having a
test that the admin doesn't cause on exception on a bad parameter.
Well, I've probably spent more time writing about this small problem
than it's really worth. :) Simply having custom filterspecs will be
useful regardless of the details of how they are implemented. Thanks
to André for updating my patch--I was going to do it, but you beat me
too it.
Cheers,
Ben
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
