Re: URL dispatcher fallthrough?

[Jacob Kaplan-Moss]

I think it's esoteric enough that mentioning it in the docs doesn't
seem like it's worth the distraction. But the wiki's, um, a wiki... so
feel free to edit!

Jacob

On Wed, Apr 3, 2013 at 9:07 AM, Felipe Prenholato  wrote:
> Jacob, I know that Django don't refer to third party packages in docs, but
> is possible to have something in doc or wiki (and doc linking to wiki) about
> this url helper (and possible others)? I ask because I see functionality
> proposed by this thread and by your app good enough to be cited in some
> place close to official docs.
>
> Felipe 'chronos' Prenholato.
> Linux User nº 405489
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc
>
>
> 2013/4/2 Jacob Kaplan-Moss 
>>
>> On Tue, Apr 2, 2013 at 4:49 AM, David Danier 
>> wrote:
>> > This is somethign that does not need to be inside Django core. So why
>> > not just start an thirt party app implementing the proposal?
>>
>> I did just that: https://pypi.python.org/pypi/django-multiurl.
>>
>> Turns out it takes a fair bit of spelunking inside the guts of the
>> urlresolver, but ends up being a fairly short bit of code. Give it a
>> shot, let me know if it works for your usecase(s).
>>
>> Jacob
>>
>> --
>> 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.
>>
>>
>
> --
> 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.
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Felipe Prenholato]

Jacob, I know that Django don't refer to third party packages in docs, but
is possible to have something in doc or wiki (and doc linking to wiki)
about this url helper (and possible others)? I ask because I see
functionality proposed by this thread and by your app good enough to be
cited in some place close to official docs.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/4/2 Jacob Kaplan-Moss 

> On Tue, Apr 2, 2013 at 4:49 AM, David Danier 
> wrote:
> > This is somethign that does not need to be inside Django core. So why
> > not just start an thirt party app implementing the proposal?
>
> I did just that: https://pypi.python.org/pypi/django-multiurl.
>
> Turns out it takes a fair bit of spelunking inside the guts of the
> urlresolver, but ends up being a fairly short bit of code. Give it a
> shot, let me know if it works for your usecase(s).
>
> Jacob
>
> --
> 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.
>
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Jacob Kaplan-Moss]

On Tue, Apr 2, 2013 at 4:49 AM, David Danier  wrote:
> This is somethign that does not need to be inside Django core. So why
> not just start an thirt party app implementing the proposal?

I did just that: https://pypi.python.org/pypi/django-multiurl.

Turns out it takes a fair bit of spelunking inside the guts of the
urlresolver, but ends up being a fairly short bit of code. Give it a
shot, let me know if it works for your usecase(s).

Jacob

-- 
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.

Re: URL dispatcher fallthrough?

[David Danier]

> David: The slugs wouldn't be overlapping if they inherited from some
> sort of "Organization" model with unique slug. The user could also add
> validation code to prevent company and schools having same slugs.

If you have a common base model this sounds like some polymorphic model
problem, which does not need to be solved in the URLs (and probably
should not). There are existing third party solutions, which may help
you get the right model back, when fetching one "Organization".

An user validation is only useful if you put the logic into an unrelated
app, as my proposed alias app. Otherwise you will need to mix your
models, at least when doing validation. This may not follow the loose
coupling philosophy
(https://docs.djangoproject.com/en/dev/misc/design-philosophies/) of
Django. If you have this app the name resolution can be done without
doing fallbacks anywhere in your code.

Anyways, about your proposal:
This is somethign that does not need to be inside Django core. So why
not just start an thirt party app implementing the proposal?

David

-- 
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.

Re: URL dispatcher fallthrough?

[Michael Manfre]

On Thu, Mar 28, 2013 at 10:28 PM, meric  wrote:
>
> Michael: How does the middleware work with other URLs that do not need to
> have fallthrough? Do you have to add them to excluded_path_patterns?
> Would like a more general description of how it works.
>

A ContentMiddleware behaves basically the same as a standard 404
middleware. If no other middleware or view handles the request, then a
ContentMiddleware will get a chance to match during the process_response
phase. Most of these middleware are a shim to a view function, but some
include logic to make faster (than the view) determinations about the user,
type of asset, the request, and whether or not the underlying views could
possibly handle request. Most of our content is subject to record level
authorization checks that result in heavy queries and reducing response
time was one of the main goals of this implementation.

There are three possible types of matches that can happen for a middleware
and a request; an explicit match, an explicit miss, and an implicit match.
An explicit miss only happens when the middleware's process() raises
Http404. An explicit match is when a response is returned, either of the
ContentHandled exceptions are raised, or a permission error is raised. The
ContentHandled exceptions allow the implementing middleware to pass back
knowledge of owned URL spaces or assets that could exist at some point in
the future. For our site, when a permission check fails, it means the
assets exists. The implicit matching happens on all other exceptions.

The type of match dictates how long to cache the knowledge about whether or
not the request was handled by the middleware. Each middleware dictates
what it means for it to match and this is often more than just the URL
pattern.

During the middleware process_request phase, any previously matched request
is immediately processed by the middleware. This short circuits the URL
dispatcher and reduces the overall response time for handling the request.
On our system, users are able to arbitrarily place assets in the URL
structure and these often overlap with the URL patterns of our views. Some
of the overlapped views have heavy look ups that could take a few hundred
ms before finding out it is and probably always will be a 404.

The excluded_path_patterns provides an easy way of explicitly missing based
upon the URL without needing to check the database. This also yields a
faster response time by avoiding any lookups when the middleware attempts
to determine "is this mine" for a new request. We also use
excluded_path_patterns to help enforce business rules about the URL space
where assets may reside. The example ManualPageMiddleware explicitly
prevents any static pages from being found under our image folder. The
underlying ManualPage model is generic and has no such restrictions for its
URL.

Also, couldn't the caching logic, (ignoring fallthrough urls for a minute),
> be implemented in a view decorator (which is also what how we do it)?
>

Basic caching logic could be worked in to a view decorator, but it will not
provide responses as quickly as my middleware. The decorated views would be
processed in order and you could end up with a request chasing just behind
expiring cache entries and having to recheck them all. My middleware is
able to check the "is this handled" cache for all of the middleware before
needing to go through the URL dispatcher and then trying each of the
middleware. You could probably get similar behavior with a decorator
wrapping several entries in urls, but it would be a bit ugly and less
flexible with cache timeouts.

Regards,
Michael Manfre

-- 
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.

Re: URL dispatcher fallthrough?

[meric]

In this mailing list alone, Michael, Tom, David, Felipe, julianb, Ian and I 
have all proposed different solutions. 7 different solutions to what 
appears to be a very common problem. :(

Tom: 

As you said the get_instance_or_404 only works for simple cases.

The switcher view only works if the delegates have no kwargs, or if they 
do, all their kwargs are named the same way. The problem remains: URL 
structure forcing a particular design onto user's view definitions.

Good point about the middleware:

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.
>
>
Currently in my pull request they do get called again and I see it is a 
problem.

David: The slugs wouldn't be overlapping if they inherited from some sort 
of "Organization" model with unique slug. The user could also add 
validation code to prevent company and schools having same slugs.

Michael: How does the middleware work with other URLs that do not need to 
have fallthrough? Do you have to add them to excluded_path_patterns? Would 
like a more general description of how it works. Also, couldn't the caching 
logic, (ignoring fallthrough urls for a minute), be implemented in a view 
decorator (which is also what how we do it)?

I have thought about some of everyone's proposed solutions, especially 
Ian's and Tom's. What about a new function for use when declaring 
urlpatterns, called "urlrouter_view" which you wrap around URLs to 
explicitly mark them as having fallthrough enabled. When calling it, it 
will look at its arguments to make sure the patterns are all identical. It 
creates an anonymous view that would route to each view one by one until 
one resolves without raising the DoesNotResolve exception. If no view could 
handle the URL, it will raise an Http404. (Since the number of URLs are 
more limited, maybe we can do away with DoesNotResolve and use a Http404 as 
a signal to continue resolving.)  Any view middleware would only have been 
run once for the URL, given the anonymous view as the argument and any 
keyword arguments are converted to list argument format for the middleware. 

Here is an example (forgive my poorly named views):

urlpatterns += patterns('',
# ... other normally managed urls.
urlrouter_view(
url(r'^(?P[_a-z0-9-]+)/(?P[_a-z0-9-]+)/$', 
'list_activity'),
url(r'^(?P[_a-z0-9-]+)/(?P[_a-z0-9-]+)/$', 
'list_company'),
url(r'^(?P[_a-z0-9-]+)/(?P[_a-z0-9-]+)/$', 
'list_activity'),
),
# ... other normally managed urls.
)

So basically my proposal as it stands but its abilities have to explicitly 
marked in urls.py. I have not thought about how this can be implemented 
yet, especially in regards to url includes and exposing the url names and 
kwargs to reverse, but it addresses the problem with view_middleware.

Alternative syntax (names can be improved), removes repetition on regex:

urlpatterns += patterns('',
# ... other normally managed urls.
urlrouter_view('^([_a-z0-9-]+)/([_a-z0-9-]+)/$'
view('list_activity', kwargs=['country', 'company'], 
name="list_activity),
view('list_company', kwargs=['country', 'industry'], name="
list_company),
view('list_activity', kwargs=['company', 'industry'], 
name="list_activity),
),
# ... other normally managed urls.
)

Any thoughts? 

-- 
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.

Re: URL dispatcher fallthrough?

[Michael Manfre]

On Thu, Mar 28, 2013 at 8:21 AM, Loic Bistuer wrote:

> What I would like to see:
>
> urlpatterns = patterns('',
> # Standard patterns
>  url(r'^admin/', include(admin.site.urls)),
>
> # Fallthrough patterns
> url('', include('myapp.urls'),
> url('', include('django.contrib.flatpages.urls'),
> url('', include('django.contrib.redirects.urls'),
> )
>
> Each app minds its own business and no more middleware that juggle with
> Http404.
>

Fall through URL patterns make it less clear about what view is handling a
URL. It's already known and established that you need to check middleware
for arbitrary URL handling, adding this to the URL patterns as well doesn't
feel like a step in the right direction.

Middlewares that juggle Http404 are not all bad and have the potential of
being a bit saner and faster than a URL fall through. If the dispatcher
falls through, then every URL that matches the pattern would need to hit
the database and/or include its own caching to determine if the URL is a
hit for a specific app/view. That leads to the same bit of code duplicated
in the top of almost every one of these fall through views.

With middleware, you can put all of this shared logic in a base class and
provide the ability to completely short circuit the dispatcher for known
matches. For src.org, we have a few different models with staff defined
URLs. The traditional Http404 middleware pattern was a bit repetitive and I
solved the problem with this middleware (
https://gist.github.com/manfre/5262782). The heart of the middlware is
ContentMiddleware._process(), which contains the "was this handled" logic.
The Gist includes one of the simple arbitrary URL model handlers, but we
have quite a few more.


Regards,
Michael Manfre

-- 
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.

Re: URL dispatcher fallthrough?

[David Danier]

I'm with Tom here, this just feels wrong. The whole point of urls.py is
to have a clean mapping of URLs to views.

Of course I understand your problem, so let's look at the details.

> //  # front page for country
> // / # list of schools and companies with activities
> in that industry, in that country
> /// # list of industries company has activities in, in
> that country

This breaks if an industry with the same pk/slug as a company exists
(/de/foo/ as industry and /de/foo/ as company). You would never be able
to call the company again, as the industry just overlaps. This schema
just is badly designed and not able to handle this case in a sane way.
This is true for router-views, throwing UrlNotMatched or any other way.
You basicaly loose the clean mapping of your URLs. It could even happen,
that you overlap a valid company url by adding a new industry to your
database, moving that URL to a completely new content.

(Sidenote: I think this is a problem even the Django admin has. Just add
an Model with an CharField as primary key and insert "add" into this
field. You will neven be able too edit this in the admin, as the
add_view will be called instead.)

You could of course make sure the URLs never overlap by making the slug
unique. One easy way would be to add a prefix, but then again you could
implement this in your urls.py without any hassle
("//industry-/").

Another solution might be to add a router-view, which is based on
aliases. So you could have a central db-table which stores alias to view
releations (meaning: /de/foo/ -> (industry_view, slug=foo), /de/foo-2/
-> (company_view, slug=foo), stored inside the database). This way you
could avoid overlaying and even create fallback-names for duplicate
slugs. But you need a central storage to accomplish that. (Drupal works
this way.)

Anyway, I don't think throwing UrlNotMatched is the right solution here.

David

-- 
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.

Re: URL dispatcher fallthrough?

[Loic Bistuer]

> urlpatterns = patterns('',
> (r'/([^/]+)/$', Switcher.as_view(delegates=[...])),
> (r'/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...])),
> (r'/([^/]+)/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...]))
> )

I don't see this as an improvement because you still bind together multiple 
apps into a single urlpattern. Also wrapper views might be ugly but at least 
there are explicit and easy to understand.

What I would like to see:

urlpatterns = patterns('',
# Standard patterns
 url(r'^admin/', include(admin.site.urls)),

# Fallthrough patterns
url('', include('myapp.urls'),
url('', include('django.contrib.flatpages.urls'),
url('', include('django.contrib.redirects.urls'),
)

Each app minds its own business and no more middleware that juggle with Http404.

> The view middleware question seems like another really good argument against 
> the proposed change...

As far as I'm concerned, Django middleware should have been deprecated 
altogether, that's certainly too late to do it now but let's not use them as an 
excuse to prevent improving the flexibility of the URL dispatcher.

-- 
Loic

-- 
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.

Re: URL dispatcher fallthrough?

[Tom Christie]

>
> 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.

Re: URL dispatcher fallthrough?

[meric]

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.

Re: URL dispatcher fallthrough?

[meric]

Hi Tom, interested to see why you think a single wrapping view is a 
reasonable alternative for the example I showed above, where you have 
following list of URLs:

//  # front page for country
// / # list of schools and companies with activities in 
that industry, in that country
/// # list of industries company has activities in, in 
that country
 # list of activities company has in that 
industry, in that country
/// # list of activities school has in that country
 # list of activities school has, in that 
industry
/ / # list of schools and companies with activities in that 
industry, in all countries
// # list of industries company has, globally
/// # list of activities company has in that industry, 
globally
// # list of industries the school is involved in, globally
///  # list of activities school has in that industry, 
globally

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 like 

router_view1(slug1=None)
router_view2(slug1=None, slug2=None)
router_view3(slug1=None, slug2=None, slug3=None)

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.

Yet, in urls.py, all you have is:

(r'/')
(r'//')
(r'///')

Forcing the user to handle complex logic like this (each user probably 
needs to do it differently), which is not easy to test due to many branches 
involved, IMHO is a big cost.

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.

Perhaps you have a better way to implement this than what I can think of? 
This is how we do it in our company, and it'd be great if this can be 
improved.

On Thursday, March 28, 2013 3:28:10 AM UTC+11, Tom Christie wrote:
>
> For what it's worth I'd be against this proposal as it stands.
>
> * I haven't seen anything anything that convinces me that a single 
> wrapping view isn't a reasonable alternative in the examples cited.
> * 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.

Re: URL dispatcher fallthrough?

[Tom Christie]

For what it's worth I'd be against this proposal as it stands.

* I haven't seen anything anything that convinces me that a single wrapping 
view isn't a reasonable alternative in the examples cited.
* 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

On Tuesday, 26 March 2013 17:49:07 UTC, Val Neekman wrote:
>
> +1 here! 
>
> It might also be a great feature to run the 404 through before sending 
> that email out. 
> A replacement and/or complement to IGNORABLE_404_URLS 
>
> Val 
>
>
> On Tue, Mar 26, 2013 at 1:25 PM, Loic Bistuer 
>  
> wrote: 
> > +1 for me. 
> > 
> > Having a catchall view under a single URL pattern is a tightly coupled 
> > system, more so than allowing independent views to "test the water". 
> > 
> > Django core relies on middleware hacks because the URL dispatcher is 
> missing 
> > this very feature. Having this in core would allow a cleaner 
> implementation 
> > of the fallback mechanisms in contrib.flatpages and contrib.redirects. 
> > 
> > -- 
> > Loic 
> > 
> > On Mar 19, 2013, at 11:18 PM, Adrian Holovaty 
> >  
> wrote: 
> > 
> > I'd rather not add this to the framework, as it's already possible 
> > with a "wrapper" view (as others have suggested). And on a more 
> > theoretical level, it introduces more coupling between URL patterns 
> > and views. 
> > 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@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. 
> > 
> > 
>

-- 
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.

Re: URL dispatcher fallthrough?

[Val Neekman]

+1 here!

It might also be a great feature to run the 404 through before sending
that email out.
A replacement and/or complement to IGNORABLE_404_URLS

Val


On Tue, Mar 26, 2013 at 1:25 PM, Loic Bistuer  wrote:
> +1 for me.
>
> Having a catchall view under a single URL pattern is a tightly coupled
> system, more so than allowing independent views to "test the water".
>
> Django core relies on middleware hacks because the URL dispatcher is missing
> this very feature. Having this in core would allow a cleaner implementation
> of the fallback mechanisms in contrib.flatpages and contrib.redirects.
>
> --
> Loic
>
> On Mar 19, 2013, at 11:18 PM, Adrian Holovaty  wrote:
>
> I'd rather not add this to the framework, as it's already possible
> with a "wrapper" view (as others have suggested). And on a more
> theoretical level, it introduces more coupling between URL patterns
> and views.
>
>
> --
> 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.
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Loic Bistuer]

+1 for me.

Having a catchall view under a single URL pattern is a tightly coupled system, 
more so than allowing independent views to "test the water".

Django core relies on middleware hacks because the URL dispatcher is missing 
this very feature. Having this in core would allow a cleaner implementation of 
the fallback mechanisms in contrib.flatpages and contrib.redirects.

-- 
Loic

On Mar 19, 2013, at 11:18 PM, Adrian Holovaty  wrote:

> I'd rather not add this to the framework, as it's already possible
> with a "wrapper" view (as others have suggested). And on a more
> theoretical level, it introduces more coupling between URL patterns
> and views.

-- 
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.

Re: URL dispatcher fallthrough?

[Andre Terra]

On Tue, Mar 26, 2013 at 10:44 AM, meric  wrote:

> Thinking through Adrian's post and mine above, it appears to be a trade
> off between coupling in the framework and increased responsibility for user
> views code. Personally I would opt for the former, because IMHO the idea of
> a framework is to reduce responsibility of user code and promoting same
> sets of design patterns for common problems (rather than each similar
> program having different adhoc ways to deal with the same problems I.e
> rather than having different ways people would implement a catch all view,
> have views send the same signal if the given arguments were not
> interpretable.) first before anything else, otherwise what else can a
> framework provide?.


Even though I suggested the use of a catch-all view for handling multiple
objects in the beginning of the thread, I now see the value of moving this
to urls.py. For more complex websites and scenarios, some patterns may
emerge that lead to such a number of possibilities that at some point, from
a design perspective, you start wondering if you're not packing too much
routing into the views (with a catch-all view) when they should be handled
by the URL routing module.

Previously -1, now +1 on this idea.


Cheers,
AT

-- 
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.

Re: URL dispatcher fallthrough?

[meric]

Previous discussion (which I've read before): 
https://code.djangoproject.com/ticket/16774 

-- 
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.

Re: URL dispatcher fallthrough?

[meric]

I've previously raised this idea and created a pull request.

https://github.com/django/django/pull/378

The problem with creating with a catch all view:

You have following models:

Country, Industry, Company, School.

You want to have the following kinds of urls:

//
// /
///

///

/ /
//
///
//
///

It can get extremely cumbersome to use catch-all views to manage all of 
these URLs, rather than a single view with optional keyword-arguments.

In my example I have only listed 4 models. It wouldn't be implausible to 
suggest there are situations when there could be more.

I suggest it is better for the framework to handle this complex URL routing 
on the urls.py level, because it really isn't the view's responsibility to 
think about URLs; Since URLs already introspect into view's arguments, and 
in some cases, even instantiate class based views, especially generic 
views, it would be better to keep urlresolver's relationship with views 
instead of introducing a new relationship where views must now take care of 
URLs too.

I think the Inversion of Control principle would be good to 
follow: http://en.wikipedia.org/wiki/Inversion_of_control








On Tuesday, March 19, 2013 2:23:41 AM UTC+11, julianb wrote:
>
> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several 
> categories and maybe associated an occasion. Now you want to build URLs. So 
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>
> Look simple.
>
> Because product slugs should generally be different to category slugs and 
> occasions, you expect no clashes here. And you don't want to bloat the URLs 
> by putting product/ and category/ in there. And you also do not want to 
> resort making it look cryptic by having just /p// and so on.
> Then it comes to Django. How do you do that?
>
> Well, at the moment, as far as I am aware, you can't. The first URL will 
> match everything all the time, not giving the other views a chance to kick 
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?
>

-- 
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.

Re: URL dispatcher fallthrough?

[Ian Kelly]

On Tue, Mar 19, 2013 at 12:26 PM, Felipe Prenholato
 wrote:
> Hi Julian. My 2 cents.
>
> What you want is:
>
> urlpatterns = patterns('',
> url_fallthrought(r'^(?P[-\w]+)$',
> views=[(ProductView.as_view(),
>CategorView.as_view(),
>OccasionView.as_view())], name="my_super_url"),)

def view_chain(views):
def inner(*args, **kwargs):
for view in views:
try:
return view(*args, **kwargs)
except Http404:
pass
raise Http404
return inner

urlpatterns = patterns('',
(r'^(?P[-\w]+)$',
 view_chain([ProductView.as_view(),
 CategoryView.as_view(),
 OccasionView.as_view()]), name="my_super_url"),
)

-- 
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.

Re: URL dispatcher fallthrough?

[Felipe Prenholato]

Hi Julian. My 2 cents.

What you want is:

urlpatterns = patterns('',
url_fallthrought(r'^(?P[-\w]+)$',
views=[(ProductView.as_view(),
   CategorView.as_view(),
   OccasionView.as_view())], name="my_super_url"),)

But you know that we don't have it. To make it works you will need to do
some loop on views and answer with first that not raises 404, and than
return it response. To be better you just run get_object() of view and
after return get() or post(). It should be done on object (wrapper view?)
that url_fallthrought returns. This will be very very similar to what you
will do if use a wrapper view... to not say same code.

This functionality will be used mostly by Django based CRMs, Blogs and
E-commerce solutions, lot of people of course, but in my opinion is so
simple to do that don't need to be in Django itself.

Att,

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/3/19 Adrian Holovaty 

> On Mon, Mar 18, 2013 at 10:23 AM, julianb  wrote:
> > Well, at the moment, as far as I am aware, you can't. The first URL will
> > match everything all the time, not giving the other views a chance to
> kick
> > in.
> >
> > So I propose some kind of URL fallthrough. The view could do
> >
> > raise UrlNotMatched
> >
> > and the dispatcher goes to the next possible matching view.
> >
> > Would that be good? Any thoughts?
>
> Hi Julian,
>
> I'd rather not add this to the framework, as it's already possible
> with a "wrapper" view (as others have suggested). And on a more
> theoretical level, it introduces more coupling between URL patterns
> and views.
>
> Adrian
>
> --
> 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.
>
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Adrian Holovaty]

On Mon, Mar 18, 2013 at 10:23 AM, julianb  wrote:
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?

Hi Julian,

I'd rather not add this to the framework, as it's already possible
with a "wrapper" view (as others have suggested). And on a more
theoretical level, it introduces more coupling between URL patterns
and views.

Adrian

-- 
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.

Re: URL dispatcher fallthrough?

[Tom Evans]

On Mon, Mar 18, 2013 at 3:23 PM, julianb  wrote:
> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>

Really straying into user talk now...

If you have a heterogeneous hierarchy of objects that have slugs, and
you wish to look up arbitrary objects by slug, perhaps just go the
whole hog, add a SluggedItem model with a generic foreign key, and a
view that fetches items from their slugs and dispatches to the
appropriate view.

Cheers

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.

Re: URL dispatcher fallthrough?

[julianb]

A single pattern with a catchall view is certainly a way to go. However, I 
really does not help to see what the views do. And if you have different 
views with different arguments, you cannot do your regex explicitly.
You are right that it is non-obvious when the view itself has to invoke the 
fallthrough. So I'm thinking it would be better in the urlpatterns itself. 
Then it is explicitly clear, rather than having some catchall magic do-all 
views and patterns. Right?

On Monday, March 18, 2013 4:44:19 PM UTC+1, Andrew Ingram wrote:
>
> The approach we take at work is to have a view that wraps around the 
> product, category and occasion views and takes care of the fallthrough 
> logic. I'm not a fan of this approach, because it means that you can't just 
> look at the urlconf and see which pattern maps to which view function. On 
> the other hand, I don't think your solution would solve this either, you'd 
> end up having 3 patterns that could all match, making it non-obvious what 
> the behaviour is.
>
> Obviously the ideal solution is to scope URLs correctly to avoid all this 
> in the first place, but I've found that in the real world this is easier 
> said than done. So it would be nice to have an idiomatic solution.
>
> An alternative might be a kwarg on the url function, such as 
> 'fallthrough_on_404'. But it all feels a bit hackish to me :/
>
> Regards,
> Andy
>
>
> On 18 March 2013 15:23, julianb  wrote:
>
>> Hi,
>>
>> imagine the following use case:
>>
>> You build an online store where you have sorted products into several 
>> categories and maybe associated an occasion. Now you want to build URLs. So 
>> the URL schema that all of the store's owners agree on is:
>>
>> //
>> //
>> //
>>
>> Look simple.
>>
>> Because product slugs should generally be different to category slugs and 
>> occasions, you expect no clashes here. And you don't want to bloat the URLs 
>> by putting product/ and category/ in there. And you also do not want to 
>> resort making it look cryptic by having just /p// and so on.
>> Then it comes to Django. How do you do that?
>>
>> Well, at the moment, as far as I am aware, you can't. The first URL will 
>> match everything all the time, not giving the other views a chance to kick 
>> in.
>>
>> So I propose some kind of URL fallthrough. The view could do
>>
>> raise UrlNotMatched
>>
>> and the dispatcher goes to the next possible matching view.
>>
>> Would that be good? Any thoughts?
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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.
>>  
>>  
>>
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Chris Wilson]

Hi Julian,

On Mon, 18 Mar 2013, julianb wrote:


imagine the following use case:

You build an online store where you have sorted products into several 
categories and maybe associated an occasion. Now you want to build URLs. So the 
URL schema that all of the
store's owners agree on is:

//
//
//

Look simple.

Because product slugs should generally be different to category slugs and 
occasions, you expect no clashes here. And you don't want to bloat the URLs by 
putting product/ and
category/ in there. And you also do not want to resort making it look cryptic by 
having just /p// and so on.
Then it comes to Django. How do you do that?


I put the type in the URL to make it obvious. That doesn't harm SEO and 
makes your URL routing clearer. For example:


/product//
/category//
/occasion//

But that's getting into django-users territory.

Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
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.

Re: URL dispatcher fallthrough?

[Andre Terra]

Hi, Julian

I think this problem can already be addressed by having a single catchall
// URL pattern, and writing a SlugHandlerView which would try
different options  within the view code, rather than in the URL dispatching.

Then it would just be a matter or catching exceptions for your .get()
methods, and raising a final 404 in case nothing is found, which would in
turn make this a django-users sort of question from here on.

Unless I'm missing something, this behavior can be achieved with what's
already in core today.


Cheers,
AT


On Mon, Mar 18, 2013 at 12:23 PM, julianb  wrote:

> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>
> Look simple.
>
> Because product slugs should generally be different to category slugs and
> occasions, you expect no clashes here. And you don't want to bloat the URLs
> by putting product/ and category/ in there. And you also do not want to
> resort making it look cryptic by having just /p// and so on.
> Then it comes to Django. How do you do that?
>
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?
>
> --
> 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.
>
>
>

-- 
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.

Re: URL dispatcher fallthrough?

[Andrew Ingram]

The approach we take at work is to have a view that wraps around the
product, category and occasion views and takes care of the fallthrough
logic. I'm not a fan of this approach, because it means that you can't just
look at the urlconf and see which pattern maps to which view function. On
the other hand, I don't think your solution would solve this either, you'd
end up having 3 patterns that could all match, making it non-obvious what
the behaviour is.

Obviously the ideal solution is to scope URLs correctly to avoid all this
in the first place, but I've found that in the real world this is easier
said than done. So it would be nice to have an idiomatic solution.

An alternative might be a kwarg on the url function, such as
'fallthrough_on_404'. But it all feels a bit hackish to me :/

Regards,
Andy


On 18 March 2013 15:23, julianb  wrote:

> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>
> Look simple.
>
> Because product slugs should generally be different to category slugs and
> occasions, you expect no clashes here. And you don't want to bloat the URLs
> by putting product/ and category/ in there. And you also do not want to
> resort making it look cryptic by having just /p// and so on.
> Then it comes to Django. How do you do that?
>
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?
>
> --
> 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.
>
>
>

-- 
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.

URL dispatcher fallthrough?

[julianb]

Hi,

imagine the following use case:

You build an online store where you have sorted products into several 
categories and maybe associated an occasion. Now you want to build URLs. So 
the URL schema that all of the store's owners agree on is:

//
//
//

Look simple.

Because product slugs should generally be different to category slugs and 
occasions, you expect no clashes here. And you don't want to bloat the URLs 
by putting product/ and category/ in there. And you also do not want to 
resort making it look cryptic by having just /p// and so on.
Then it comes to Django. How do you do that?

Well, at the moment, as far as I am aware, you can't. The first URL will 
match everything all the time, not giving the other views a chance to kick 
in.

So I propose some kind of URL fallthrough. The view could do

raise UrlNotMatched

and the dispatcher goes to the next possible matching view.

Would that be good? Any thoughts?

-- 
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.