The way I stumbled across this problem was:

1. views imports models and forms (both are normally needed)

2. forms imports models (for ModelForm)

3. models imports views (for get_absolute_url), e.g.:

import views
class MyModel(models.Model):
        get_absolute_url(reverse(views.myview))

which leads to a circular dependency of the form views->forms->models->views.

I searched and there are some questions raised in stackoverflow about it, e.g. 
this, this.
This is avoided by removing one of the imports, and in this
case the candidate is 3., replacing it with a string (e.g. 'views.myview').

I propose that we add a note on the documentation of get_absolute_url
explaining that get_aboslute_url should be coded by returning reverses of 
strings and
not of functions or classes to avoid circular dependencies.

There is a ongoing thread about get_absolute_url and I think these problems are
somewhat related: this circular dependency is a valid mistake from a
Django user because models are depending on views, views on forms, forms on 
models.

Another reason why I think this should be documented is that circular 
dependencies
are difficult to debug, specially when they occur after modules are imported 
like import module.

This also makes the documentation more consistent: Foreign Key already warns 
about circular dependencies:

"This sort of reference can be useful when resolving circular import 
dependencies between two applications."

In summary, I agree that the url's "anti-circular dependency" is correctly 
fixed from the implementation point of view by allowing strings,
what I'm proposing is just to document why users should use it, i.e. what they 
are useful for, specially in the models' get_absolute_url.

If no one objects, I can do this.

Regards,
Jorge

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to