URL namespaces

[Marten Kenbeek]

Hi all,

URL namespaces have a few quirks that make them a bit difficult to use and 
understand. I hope to create a patch that clears up these issues. 

First up: the distinction between an application namespace and an instance 
namespace. The docs say on the application namespace:

This describes the name of the application that is being deployed. Every 
> instance of a single application will have the same application namespace.


And on the instance namespace: 

This identifies a specific instance of an application. Instance namespaces 
> should be unique across your entire project. However, an instance namespace 
> can be the same as the application namespace. This is used to specify a 
> default instance of an application. 


The current implementation requires that both are specified in the same 
place: either in the included url configuration by returning a 3-tuple, or 
in the including url configuration through the arguments to include(). The 
first case generally does not allow multiple deployments of the same app, 
unless the included url configuration contains specific logic to return 
different instance namespaces. The second case does not in any way enforce 
that multiple deployments in fact have the same application namespace. 

I'd like to get the semantics and the implementation in line, and provide 
one obvious way to specify namespaces. Including a set of url patterns 
under a namespace involves two parts: the including urlconf that calls 
include(), and the included urlconf that is imported by include(). The 
first is a specific deployment of the imported urlconf; the second is a 
single app. 

The obvious way as I see it would be to specify the application namespace 
in the app, and specify the instance namespace as a parameter to include(). 
This enforces the single application namespace for a single set of 
patterns, and allows any end-user to specify the instance namespace on a 
per-instance basis. To take the admin as an example:

admin.site.urls would return a 2-tuple: (patterns, 'admin'), where 'admin' 
is the application namespace. (An alternative to a 2-tuple could be an 
object with urlpatterns and app_name attributes.)
To include the admin instance, use include(admin.site.urls, 
namespace='admin'). This is the instance namespace. If left out, it could 
default to be the same as the app name.

After a deprecation period, it would be an error to specify an instance 
namespace if there is no application namespace. This is to ensure that the 
app can always reverse its own urls using : if it 
specifies an application namespace, and using  if it doesn't. 
(Setting and app_name would technically still be possible by passing a 
hardcoded (patterns, app_name) tuple, just not as an advertised feature.)

The second point is about nested namespace handling and current_app. 

At the moment, current_app is looking for an exact namespace match. Unlike 
the namespaced view path, it is not split into namespace parts using 
current_app.split(':'). Take the following (fictional) urlpatterns:

blog_patterns = [
url(r'^comments-one/', include('comments.urls', 'comments-one', 
'comments')),
url(r'^comments-two/', include('comments.urls', 'comments-two', 
'comments')),
]

urlpatterns = [
url(r'^blog-one/', include(blog_patterns, 'blog-one', 'blog')),
url(r'^blog-two/', include(blog_patterns, 'blog-two', 'blog')),
]

Because of how current_app is handled, it is now impossible to reverse 
patterns in 'blog-one:comments-one:' using current_app. To select 
'blog-one', the current app needs to be the string 'blog-one', but to 
select 'comments-one', it needs to be 'comments-one'. The only solution is 
to hardcode at least one of the instance namespaces in the namespaced view 
path. This also means that setting request.current_app to 
request.resolver_match.namespace, as recommended in the docs, does not work 
if you have nested namespaces. 

The ResolverMatch object also has some inconsistent behaviour for app_name. 
resolver_match.namespace is the full namespace path, i.e. 
'blog-one:comments-one' (with resolver_match.namespaces a list of 
individual namespaces, i.e. ['blog-one', 'comments-one']), but 
resolver_match.app_name is the outer-most app_name, in this case 
'blog-one', with no trace whatsoever of the full app_name path. 

To illustrate how I would see it end up eventually (after the deprecation 
cycle), I've created a branch at 
https://github.com/knbk/django/tree/namespaces. I feel these changes are 
fairly straightforward, but any comments are appreciated. 

Marten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

Re: Why can't templates access properties

[Ram Rachum]

Created: https://code.djangoproject.com/ticket/24863#ticket

On Wed, May 27, 2015 at 2:56 AM, Curtis Maloney 
wrote:

> Feel free to open a ticket, as it will give a place to retain the
> discussion.
>
> Perhaps start with the use case for having additional properties on a
> QuerySet :)
>
> --
> Curtis
>
> On 27 May 2015 at 07:14, Ram Rachum  wrote:
>
>> I found the cause of my problem: `django.db.models.Manager.from_queryset`
>> copies all the methods from the `QuerySet` class to the `Manager` class,
>> but it doesn't copy the properties.
>>
>> What do you think about opening an issue for
>> making `django.db.models.Manager.from_queryset` copy over properties as
>> well?
>>
>>
>> On Tuesday, May 26, 2015 at 10:19:25 PM UTC+3, Tim Graham wrote:
>>>
>>> Accessing properties in templates should work as far as I know. Maybe
>>> there is an error in your application.
>>>
>>> On Tuesday, May 26, 2015 at 2:27:40 PM UTC-4, Ram Rachum wrote:

 Hi,

 I noticed that when I use variables in Django templates that access
 object properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is
 a Python property.)

 See the documentation for variables in Django templates:

 https://docs.djangoproject.com/en/1.8/ref/templates/language/#variables

 It indeed doesn't mention properties.

 Why should properties not work through template? I can't think of a
 good reason.


 Thanks,
 Ram.

>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@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/7188bfd5-632d-4333-868f-180540a8193c%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/e6SOZNs0GVU/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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/CAG_XiSCa5%3DS3JNyJ0zNwBAmkObj9%2B3oyOeKUE_1a8yYu7%3DgoNA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CANXboVaq%2BsW3MmCirheR_NQPyDnyPst7a_9xAQTxkK3fkkc80g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.