Match multiple URLs to the same pattern

[Mathew Byrne]

I have an application that requires a flat URL structure for multiple different views.  The single route r"^[\w\-]+" should start by looking at slugs for one Model class, and move onto a Category Model class if no match is found, then a Vendor model class, and lastly down to the flatpages app.

I'd like to separate all these models into separate views, but regular django urlpatterns wont work here since only the first match is followed.

What's the best way to implement this requirement?  Is there a way I can create my own URL matcher and dispatch to a view based on custom logic?  Is there a way to re-dispatch a request after the point at which a match was made?

Thanks,

Mat

[Avraham Serour]

What do you mean by flat URL structure?

In any case you may have a controller called by the URL dispatcher that decides which view to use to process the request.

No need to complicate on writing you own dispatcher replacement

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4124aceb-0572-4ee9-ad11-63eb71f71c01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bill Freeman]

You will want a routing view, or a fallback cascade.  In either case, make that urlpattern r'^([\w-]+)$'.  You don't need to escape the - because it's the last char in the class.  You don want to restrict the urls to those in which the entire url matches (^ and $), and the parentheses capture the string as a positional argument to the view.  Your view could then call sub views, something like this:

    def router(request, key):

        try:

            return model1_view(request, key)

        except django.http.Http404:

            pass

and as many more try blocks as you need.

Don't put the last sub view in a try lock so that if it's not found anywhere, the 404 takes its natural course.

Each view can use the get_object_or_404() shortcut, or whatever floats your boat.  It's just that they should raise Http404, rather than formatting the 404 response themselves and returning it

The sub views can be class based, so long as they raise Http404 for no such key, or be function views

Doing the outer, routing view, as a class based view is probably less clear (less explicit), and is left as an exercise for the student, if you really want it.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tKunbukyag%3DNkO%3D-E2c61vQErnRqjSgXjnuvO4h1MNgWA%40mail.gmail.com.

[Mathew Byrne]

Thanks, yes this is exactly what I'm after.

I'm coming from other web frameworks where there is more "magic" around controllers/views so I was unsure about this solution, but in django it appears that a view is explicity just a function that transforms a request into a response.

Thanks again.

[Derek]

Yes; Django says pretty much this same thing "on the tin":

"A view function, or view for short, is simply a Python function that takes a Web request and returns a Web response."  ( https://docs.djangoproject.com/en/dev/topics/http/views/ )

(I think there *is* magic in Django; but its in the inherent clear design and usage patterns that "just work".)