Tim, this is not about documentation. It's a question of whose responsibility this (setting the current_app) is. The reusable app code (where one would set the current_app) is out of pjotr's control, unless he forks it and makes a fix.
Making a fix is not that bad but the problem is that very few reusable app authors correctly handle the namespace issue. I for one can't name one reusable app that correctly sets the current_app - which leads me to believe there's something wrong in how Django handles this.
Django should have a default current_app in the RequestContext. Maybe this should be brought up on django-dev mailing list, or even a bug report.
Meanwhile this can be handled with a custom context processor (TEMPLATE_CONTEXT_PROCESSORS setting) that does something like:
def add_namespace_processor(request):
return {'current_app': request.resolver_match.namespace}
On Monday, December 1, 2014 4:33:40 PM UTC+2, Tim Graham wrote:
-- Making a fix is not that bad but the problem is that very few reusable app authors correctly handle the namespace issue. I for one can't name one reusable app that correctly sets the current_app - which leads me to believe there's something wrong in how Django handles this.
Django should have a default current_app in the RequestContext. Maybe this should be brought up on django-dev mailing list, or even a bug report.
Meanwhile this can be handled with a custom context processor (TEMPLATE_CONTEXT_PROCESSORS setting) that does something like:
def add_namespace_processor(request):
return {'current_app': request.resolver_match.namespace}
On Monday, December 1, 2014 4:33:40 PM UTC+2, Tim Graham wrote:
Did you read about passing 'current_app' to your template rendering calls? https://docs.djangoproject.com/en/1.7/topics/http/urls/# id4
The contrib.admin class has app_name='admin' and namespace='admin' by default, but you can create a custom AdminSite(name='foo') to customize the instance namespace. In the admin's views, calls to reverse and template rendering pass (current_app=self.admin_site.name ). That should be a good example to follow in making your app reusable.
If you think the documentation could be improved, I'd happily review any patch you could submit, thanks!
On Monday, December 1, 2014 8:54:02 AM UTC-5, pjotr wrote:That is not the point. I know I can do that, but that doesn't solve the issue of an reusable app. I could fork the 'greeter' project, add my namespace in the templates, and it would be all working. But still that is not the point.The point is: how can I write a reusable app so that someone else, that uses it can namespace it into whatever namespace they want, and it should still work.
On Monday, December 1, 2014 4:35:53 AM UTC+1, WongoBongo wrote:Change all instances of this in your templates{% url 'greet' greeter.pk %}To this{% url 'greeter:greet' greeter.pk %}.
Since you are now using the 'greeter' namespace. Also, the other one is{% url 'greeter:list' %} and not {% url 'list' %} because you are using the 'greeter' namespace.
K
On Sunday, November 30, 2014 11:51:17 AM UTC-8, pjotr wrote:Alright, I'm already crazy, so the subject is a bit of a lie. But nevermind.I think I like namespacing, it is really nice. But there is something not that clear in the documentation of Django, and how to make usage of namespace, in a consistent way. Lets take it by example.I'm using this pretty amazing app "greeter" that was written by a superuser from a country far away from my own. It is a pretty simple app, that has two url mappings:url(r'^list/$', HelloWorldList.as_view(), name='list'),
url(r'^greet/(?P<pk>\d+)/$', HelloWorldGreet.as_view(), name='greet'),The template of HelloWorldList view is using the template tag url like this: {% url 'greet' greeter.pk %}.After that I hook up the application in my project by including it in my project urls.py:url(r'^greeter/', include('greeter.urls')),Everything works well, I felt like a Django guru integrating the hello world app to my own project. I can access /greeter/list and clicking on the greetings works well.Later that night I go to bed, feeling confident, kissing my wife goodnight with a smile on my face. I wake up warm, sweaty, with my heart beating. I run to my laptop, just realized I forgot to namespace the greet app, because I just realized I am using the list name in another place in my project, and I don't have any automated tests, so I better namespace it quickly.So, I change my project url mapping to this:url(r'^greeter/', include('greeter.urls', namespace='greeter')),Boom crash. Visiting the /greeter/list/ page gives me:
Reverse for 'greet' with arguments '()' and keyword arguments '{pk:1}' not found. 0 pattern(s) tried: []
I start to doubt the author of the 'greeter' app, that he didn't prepare his app for being used in other projects, where the project might need namespacing to avoid conflicts.
Digging into Django documentation, I don't really find any argument for the author of the 'greeter' app to be sloppy and not caring of details.
Someone who can enlighten me why django doesn't try to default to the current app when resolving namespaces? Or can someone enlighten me how I can help out the author of the 'greeting' app, so it really is reusable in other projects?
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/a00bf1bb-2595-4458-a443-56b641e5c8b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment