Thanks for the feedback. I assume If it's not use then performance should be the same. But I don't know if the single check for the presence of the attribute or not would affect much the performance.
The goal of this feature is offering a hook to allow people extend a bit the routing logic. Which is more difficult with Django because routing and view lookup are the same thing. @Sean , I understand your point about have a single view but I hope this could help people to organize their function based views in a nice way in the same way that required_GET could be done inside the view. Will be great if you take few min to look how this feature is used in other framework. I'm personally not convince my implementation is the right one but I hope that could open the discussion to have a more extensible routing in Django. On Wednesday, 22 May 2013 23:21:33 UTC+1, sebleier wrote: > > I think what Rach is suggesting is different from @require_GET, > @require_POST, etc. The patch essentially makes a view invisible if > the predicate function returns False. > > I'm not sure this would be good for inclusion to django, since you are > tying url resolution to application state . This could have negative > implications, especially for performance. On top of that, the same > functionality could be achieved by creating a function/class to route > the request further after django has initially routed the request. > This would be preferable because the performance hit would be isolated > to the resolved routing function/class. > > > > On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss > <[email protected]<javascript:>> > wrote: > > I'm not sure I understand what you're proposing here. How is this > > different from @require_GET, @require_POST, and friends? > > > > Jacob > > > > On Wed, May 22, 2013 at 11:05 AM, Rach Belaid > > <[email protected]<javascript:>> > wrote: > >> I just did a pull request resulting of my last Django sprints for > >> adding a new feature in Django. > >> > >> https://code.djangoproject.com/ticket/20479 > >> > >> The idea is being able to have more control on the url resolving > >> process. > >> > >> I have no merit behind the idea of predicate. Predicate is one of my > >> favorite feature in Pyramid/Pylons to allow more complex and flexible > >> routing. > >> > >> I will be curious about feebacks? Do you like this idea of features ? > >> > >> The implementation is probably imperfect so don't be too harsh ;) we > >> can always fix the implementation. > >> > >> For people unaware about what is a predicate, I advice to check the > >> pyramid doc here: > >> > http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments > > >> > >> -- > >> 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 [email protected] <javascript:>. > >> To post to this group, send email to > >> [email protected]<javascript:>. > > >> 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 [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<javascript:>. > > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
