Re: URL dispatcher fallthrough?
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?
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?
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: 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?
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?
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?
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?
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?
> 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?
> > 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?
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?
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?
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?
+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?
+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?
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?
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?. -- 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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.