ABSOLUTE_URL_OVERRIDES

[Simon Willison]

I only just found out about the ABSOLUTE_URL_OVERRIDES setting. It's
a brilliant idea (one of the main advantages of the Ruby on Rails
routes system is that it allows URLs to be resolved in either
direction) but I feel it would work better as a mechanism in the
urls/ configuration files. That way, all information relating to URLs
would be located in the same place; at the moment URL decisions are
spread across the models, the URL conf and the ABSOLUTE_URL_OVERRIDES
setting.

In fact, I would go as far to say that get_absolute_url() in the
model should be deprecated in favour of a mechanism similar to
ABSOLUTE_URL_OVERRIDES that lives in the urls configuration.

Cheers,

Simon Willison

[Adrian Holovaty]

On 10/17/05, Simon Willison <swil...@gmail.com> wrote:
> In fact, I would go as far to say that get_absolute_url() in the
> model should be deprecated in favour of a mechanism similar to
> ABSOLUTE_URL_OVERRIDES that lives in the urls configuration.

That's an interesting idea. The current thinking is that an object's
URL (or at least the logic on how to calculate it) is an intimate part
of its domain logic. Other thoughts?

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

[Ian Maurer]

One thing I really like about the URL mapping/dispatch functionality
of Django is the ability to bring in an existing app and put it in its
place within a project using whatever URL prefix you want.

For instance, a forums app can be included and one project may use:

/forums/topic/2005-05-01/new_topic/

But another project may do:

/community/messageboard/topic/2005-05-01/new_topic/

Ideally, the get_absolute_url() method could ask Django what it's
application's absolute url "prefix" is (in this case either "/forums"
or "/community/messageboard") and then build the rest of the url that
it already knows ("/topic/2005-05-01/new_topic/").

This however would require a coupling of the model to the app and the
URL dispatching stuff in order to follow the DRY principle, so I am
not sure if this follows the Django principles. But, on the other
hand, applications would be further decoupled from the projects that
contain them, making them much easier to drag and drop without
modification.

-ian

[Ian Maurer]

Sorry I didn't answer the original question... just added my own issue :)

I think my above request could be done in either the model or the URL
config file for the app. I probably prefer using the URL config file
soultion so that all of that stuff is in one place, it seems easier to
manage.

[Robert Wittams]

Hm, I can see both points of view. Eg especially in the case of
auth.User, this will get shown in different sites, so "The model should
not constrain the url layout of the site" does seem like a good rule.
Also as we would like to have more things in future that can bolt-on to
arbitrary sites, eg comments, this would become a more common requirement.

Which kind of leads me to thinking that something like PEAKs generic
functions would be a good fit. But atm that is a dependency too far ;-)

[hugo]

>That's an interesting idea. The current thinking is that an object's
>URL (or at least the logic on how to calculate it) is an intimate part
>of its domain logic. Other thoughts?

Hmm. I actually think that a URL-construction machinery that
corresponds (logically, not necessarily technically) to the urlpatterns
would be quite nice. The problem with get_absolute_url is, you need to
know in your mode how the URL space is constructed, but the URL space
should be solely in the hands of the project, not the application.

Ok, the project can delegate part of the URL space to the application
via include(), but with the current state, the model needs to know all
parts of the URL, even the project prefix that's isn't necessarily
known to the application.

bye, Georg