>
> What is the reasonable alternative? The only way I can think how a
> wrapping view will be able to handle this case, is to write your own
> router...
>
...In each case you'll have lots of ifs, try..excepts, for each model, and
> then to appropriate view. For the second and third router_views you'd have
> to have the same thing repeated, but this time it is nested.
One pattern you could use to avoid ugly nesting would be to write a helper
function that attempts a queryset lookup against multiple models, for
example...
obj = get_instance_or_404(Foo, Bar, Baz, pk=pk)
if isinstance(obj, Foo):
...
elif isinstance(obj, Bar):
...
elif isinstance(obj, Baz):
...
Something like that would probably be fine for the simpler cases.
For more complicated cases you can implement pretty much the same API
you're looking for but do it in view code. Something like this...
class Switcher(View):
"""
Delegate the handling of the request to one of a list of delegates.
Any delegate may raise an IgnoreRequest exception to pass handling
over to the next delegate in the list.
"""
delegates = []
def dispatch(self, request, *args, **kwargs):
for delegate in self.delegates:
try
return delegate(request, *args, **kwargs)
except IgnoreRequest:
pass
raise Http404
urlpatterns = patterns('',
(r'/([^/]+)/$', Switcher.as_view(delegates=[...])),
(r'/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...])),
(r'/([^/]+)/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...]))
)
There's also the question of view_middleware not being applied for the
> appropriate view unless the user specifically looks into how middleware
> gets called and manages handling view middleware themselves in the
> different router_views.
The view middleware question seems like another really good argument
against the proposed change...
The view middleware can't be called just once with the 'correct' view,
because there's not way of determining up front if a view will raise a
`UrlNotMatched` without calling into it.
So, what happens when `UrlNotMatched` is raised - do all the middleware
`process_view` methods get called again?
Cheers,
Tom :)
On Wednesday, 27 March 2013 23:27:44 UTC, meric wrote:
>
> Tom, you're right about the second and third points though. If the user
> perform any operation with side effect that requires writing to the
> database before the view checks whether the keyword arguments are
> appropriate and decide to raise DoesNotResolve, it can definitely be a
> source of non-obvious bugs and surprising behaviour. For example, a counter
> increment in the view to count how many times the view has been visited,
> placed before checking for whether to raise DoesNotResolve. Multiple such
> views get executed, multiple view counters incremented for one HTTP
> connection.
>
> I can only think of adding a stern warning to the documentation something
> along the lines of "Must not perform any operation requiring a database
> write or any other operation with side effects before the check for
> DoesNotResolve is made.".
>
> Eric
>
> On Thursday, March 28, 2013 3:28:10 AM UTC+11, Tom Christie wrote:
>>
>> * A `UrlNotMatched` exception sounds like the potential source of
>> incredibly non-obvious bugs and surprising behavior.
>> * Allow a single HTTP call to end up calling into multiple views just
>> seems like it would a fundamentally bad design decision.
>>
>> I really don't see the trade-off of allowing this type of behavior to be
>> worth the cost of breaking the current mental model of what a view is and
>> does.
>>
>> Just my personal opinion of course :)
>>
>> Tom
>>
>>>
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
