Re: An idea for the URL dispatcher
Hi Daniele,
On 03/21/2013 02:07 AM, Daniele Procida wrote:
> I think it would at minimum require hooks so that the URL dispatcher
> could call other functions, not just views.
>
> So:
>
> * the URL dispatcher could be invoked with a special argument when
> you want it not to call views but perform some other function
>
> * the URL confs could take this argument, and call the function it
> specifies instead of the usual view, failing gracefully if the
> function doesn't exist
>
>
> I guess it would have to be a keyword argument such as:
>
> { 'alternative_function': 'some.alternative.function'}
I don't think this is necessary. The url resolver module does not call
anything; it just returns ResolverMatch objects with "func", "args", and
"kwargs" attributes (where "func" is a view function). I think it would
make more sense to leave the url-resolver alone, and build your system
around it; if you have a way to map a view-func plus args/kwargs to a
model instance (which is more or less what you'll need in any
implementation of this idea), then you can get the ResolverMatch from
the url resolver and resolve that to a model.
Carl
signature.asc
Description: OpenPGP digital signature
Re: An idea for the URL dispatcher
On Wed, Mar 20, 2013, Carl Meyer wrote:
>> Often - not always but often - a Django URL will map to a model
>> instance via a URLconf and a view
>I think this is an interesting idea for some specific use cases, but I
>don't think its implementation belongs in the core url-resolver code,
>for a couple reasons
>If you work on implementing this outside Django and find that you need
>hooks that are not currently available, those hooks would making
>interesting feature proposals for Django.
Thanks for the feedback.
I think it would at minimum require hooks so that the URL dispatcher could call
other functions, not just views.
So:
* the URL dispatcher could be invoked with a special argument when you want it
not to call views but perform some other function
* the URL confs could take this argument, and call the function it specifies
instead of the usual view, failing gracefully if the function doesn't exist
I guess it would have to be a keyword argument such as:
{ 'alternative_function': 'some.alternative.function'}
In fact this would allow you to use the URL dispatcher for other URL-related
things, not just my URL-to-model functionality (though I can't think of
anything very useful just at this moment).
Then as you say the actual functionality would be built outside Django itself.
How does that sound?
Daniele
--
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: An idea for the URL dispatcher
Hi Daniele, On 03/20/2013 05:46 AM, Daniele Procida wrote: > I have an idea for the URL dispatcher, and I'd like to know what your > thoughts are. > > Often - not always but often - a Django URL will map to a model > instance via a URLconf and a view. > > I can think of a few uses for a feature that used Django's URLconfs > to return the model instance, if there is one, mapped to by a > particular URL. > > In other words, one would feed a URL to the system, which would > return a model instance, if one could be uniquely associated with > that URL. I think this is an interesting idea for some specific use cases, but I don't think its implementation belongs in the core url-resolver code, for a couple reasons: 1) The pattern is simply not common enough to require an implementation in core Django. 2) It couples the URL resolver to the ORM. These are separate modules that should not need to depend on one another, in either direction. If you work on implementing this outside Django and find that you need hooks that are not currently available, those hooks would making interesting feature proposals for Django. Carl signature.asc Description: OpenPGP digital signature
An idea for the URL dispatcher
I have an idea for the URL dispatcher, and I'd like to know what your thoughts
are.
Often - not always but often - a Django URL will map to a model instance via a
URLconf and a view.
I can think of a few uses for a feature that used Django's URLconfs to return
the model instance, if there is one, mapped to by a particular URL.
In other words, one would feed a URL to the system, which would return a model
instance, if one could be uniquely associated with that URL.
Examples of the utility of this idea:
* applications that handle links to other Django models using generic content
types often make the admin user select the object's class and instance; this
feature would allow them also to enter a URL into a form, and the system would
then select the object's class and instance, if a match can be found
* web server logs and analytics reports list URLs visited, that then have to be
interpreted; from this one could obtain a report listing actual things that
visitors were interested in
* it could be an easy way to get to the admin URL for any model instance from
its URL
Currently, Django's URLconfs are used to call views. But, I think it would be
feasible to amend them so that they could also return an object, using optional
arguments to ask it to do that instead of calling the view.
As I understand it, namespacing like:
(r'^help/', include('apps.help.urls', namespace='foo', app_name='bar')),
already helps map URLs and model instances. Then, if each particular URLconf
had an optional argument:
mapper = some_mapping_function
then as long as there is some way to tell the URL dispatcher that it should not
call the view, but instead call the mapper, it will return the model instance
if it finds one.
So my questions are:
* would this functionality be valuable
* is the concept viable
* and would it be worth the effort to develop it?
I'd certainly have a lot of use for it myself, but I don't know whether it
would be more widely useful, and I don't fully understand what would be
involved in implementing it.
Daniele
--
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.
