Monday, December 7, 2015

Re: How to write Model.get_absolute_url()?

Namespaces are a mess, and have been for a while. 1.9 cleans this up a bit. Some advice for 1.8 to stay in line with the 1.9 changes:
  • Always define an application namespace when using an instance namespace.
  • An app shouldn't depend on the project's url configuration, so always use the application namespace in the view name, i.e. reverse('polls:view'), not reverse('author-polls:view').
  • A project that uses an app may point to a specific instance namespace of that app when necessary, i.e. on the front page with links to both author-polls and publisher-polls.
  • The currently active instance namespace is available as request.resolver_match.namespace.
  • You can set request.current_app = request.resolver_match.namespace before rendering templates, and the {% url %} template tag will use the current namespace for urls in the same application namespace.
  • You can explicitly pass the current namespace to current_app in reverse() to do the same. 
The rationale behind the 1.9 changes it that an application namespace should define the name of a view, which the app must be able to know and reverse. The instance namespace defines a specific location for that view, and a project defines the exact location of that view and may even specify multiple locations. The application should typically reverse views for the currently active instance namespace, while the project may point to a specific instance namespace. By giving the app the ability to define its own application namespace, it is fully in control of its own url configuration and doesn't require any additional action from the user of the app. Since instance namespaces can no longer exist without an application namespace (well, it's deprecated anyway), it is always possible to reverse a view using the application namespace.

In 1.9, you can then just move the application namespace to the app's urlconf, and remove the request.current_app = request.resolver_match.namespace, since 1.9 does this for you. 

I hope this helps a bit. If you have any more questions feel free to ask. 

On Monday, December 7, 2015 at 10:45:07 PM UTC+1, Jon Ribbens wrote:
On Monday, 7 December 2015 21:14:45 UTC, Caique Reinhold wrote:
Well, as this is implemented you have to know your namespaces during development. But now i see what's your problem.

I'm not sure, but i don't think it is encouraged to have multiple instances of the same app in one project. I think the sites contrib app or some other method of having this author/publisher distinction within the same app would better suit your needs.

I don't have any needs (the author/publisher thing is from the Django docs, not my app), I'm just trying to write an utterly simple app and I'm trying to find out the "best practices" way of doing it.

The impression I'm getting is that the documentation is misleading and the "instance namespace" feature does not actually really work. And that the answer to my question is that I should use an app namespace and put as part of the installation instructions for my app that the user must put app_name="foo" in their site's urls.py or the app will fail. I guess this is why one of the changes in 1.9 is that now you can define the app_name in the app rather than in the site.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/78bd3615-f8eb-4236-b440-642c899bdf8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment