Change History (5)

One can argue endlessly about when a piece of code is or is not completely "decoupled"; in this case, since the application is located inside the project directory (and since there is not a guarantee that the application itself will be directly on the Python path, while the project must be in order for anything to work), I don't see a problem with leaving it as-is.

At the risk of arguing endlessly, I respectfully agree with my fellow Django initiate. If I understand the significance of apps and projects properly, this is not only not decoupled, but it is doubly coupled. If the maintainer of a project has to modify project-level settings to include someone else's application, that's understood, although the fewer modifications necessary, the better. If the maintainer of a project has to modify both the project and the application, that's not so desirable.

Is there some way that patterns() can be made to reference the invoking module without having to identify it by name?

assuming the string 'urls' doesn't appear in the project name or application name, this seems to work. I guess a regex could be used for a more general solution.

This comes up again when calling reverse() to get the URL for HttpResponseRedirect. My code:

return HttpResponseRedirect(reverse(name + '.results', args=(p.id,)))

I don't know enough about Python to work around the import line at the top of views.py, though. I guess the solution would be to include the application directory in the Python search path, as ubernostrum mentioned, in which case there are simpler fixes than those I copied above. I wonder what the security implications of doing this are.

I'm certainly curious to know how this coupling issue is handled by the Django pros