Other than using uncommon names for the url one could just use the
most obvious name and let the url tag have a disambiguation function
so if the name is: "name" you could write both:
{% url 'name' %} and {% url 'myapp.name' %} (or "myapp/name" or
"myapp-name")
With this you could keep the url management simple for most cases and
allow users to differentiate colliding names (it would be terrible
that if a name is taken by, lets say, comments or another contrib app
users had problems for setting up url names)
On Mar 29, 10:13 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-03-30 at 01:57 +0000, SmileyChris wrote:
> > On Mar 28, 9:57 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > > I've done some thinking on this, too, and I think the cleanest way to
> > > solve it would be to introduce optional names for URL patterns.
> > > Something like this:
>
> > > url(r'^objects/$', some_view, name='object_view'),
> > > url(r'^objects2/$', some_view, name='object_view2'),
>
> > How would the reverse end work? (I worry that this could easily lead
> > to view name collision between applications)
>
> Have a look at the patch I posted to this list the other day. Reverse
> works by just specifying the name -- it's even in the test in that
> patch. The string you specify can be either the "name" name or the
> function name, since they are unlikely to clash unless you have a
> twisted way of naming things.
>
> You can't completely avoid name collisions for patterns (or apps or
> command line tools or anything) and somebody using very common words as
> a name for a URL pattern in a reusable app is asking for trouble. They
> probably drive around without wearing a seatbelt, too, though. There's
> just no accounting for taste. If you expect your URL patterns to be
> reusable, make the name something that is likely to be unique (e.g. add
> the app name as a prefix, so myapp-url, for example). That reduces the
> likelihood of name collisions to the same as that for app name
> collisions, which have to be handled in the same way -- by using
> uncommon names.
>
> I thought about allowing the "name" parameter on the include() directive
> as a way of controlling the prefix for the included patterns. However,
> that would break all templates that already used the name prior to the
> prefix being added.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
