While working on this ticket, I was pondering whether we should really fix this or not because one of the core developers said,
"What is the point of fixing something that we would deprecate in a short time?"
Would it be better if we just raise error if someone provided keyword `app_name` argument in AdminSite constructor? This would not break backward-incompatibility because this bug had prevented someone to provide keyword `app_name` anyway.
Hi Vajrasky,
On Saturday, November 9, 2013 4:47:35 PM UTC+1, Vajrasky Kok wrote:While working on this ticket, I was pondering whether we should really fix this or not because one of the core developers said,
Imo fixing this won't be easy; see for instance how admin_urlname filter is implemented; we'd have a hard time passing anything else in there…
"What is the point of fixing something that we would deprecate in a short time?"
Not much.
Would it be better if we just raise error if someone provided keyword `app_name` argument in AdminSite constructor? This would not break backward-incompatibility because this bug had prevented someone to provide keyword `app_name` anyway.
Since it's already broken anyways we can just remove it instead of raising an error.
I'm a little concerned about this talk about deprecation here -- the app_name exists for a reason, and at time the app_name feature was added, it worked (to the best of my knowledge, anyway).
The use case was simple -- deploy two instances of admin in a single project. For example, you might have a truly 'access-all-areas' admin, and a cut down/modified admin for trusted editors that has specially customised workflows, etc. Admin has been specifically designed to allow this, and it's a documented feature [1].
AdminSite instances take a single argument to their constructor, their name, which can be anything you like. This argument becomes the prefix to the URL names for the purposes of reversing them. This is only necessary if you are using more than one AdminSite.
So the name of the "other admin" becomes the prefix to the URL names for the purpose of reversing them.
Now I'm more confused.
We might have to fix the docs there :)
url(r'^help/', include('apps.help.urls', namespace='foo', app_name='bar')),
(<patterns object>, <application namespace>, <instance namespace>)
--To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87b88e75-8110-4136-acd2-77408f0fe5d3%40googlegroups.com.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
On Thursday, November 14, 2013 12:55:32 PM UTC-3, Amirouche Boubekki wrote:
It's was fixed somewhat [1]. ...
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4d5401e6-0870-4a2c-a29a-9890ab6e5066%40googlegroups.com.