Feature Request: Add option to specify allow/exclude namespace options per view

[tim-mccurrach]

Motivation

If your frontend isn't a single javascript bundle, it would be a useful feature to be able to expose certain urls to certain parts of your front-end and not others. This can become important when certain parts of your site are only for authenticated users, or users with particular permissions. If you've written your own admin app, or just have a staff-only section of your site, you definitely don't want to expose these URLs to unauthenticated users. But you might also like to use django-js-reverse in your admin/staff-only section.

Allowing several views to fetch different sets of urls would solve this. Currently, this flexibility isn't possible since exclude-namespace and include-namespace options are set at the settings level.

Other benefits

• It would also make it easier to use this library in other third-party libraries. If you have a library that exposes some API, it would be a really nice 'extra' to be able to say to your users, you can use django-js-reverse in your front-end to make your life a little bit easier if you so wish (without having to do anything extra yourself).

An envisioned implementation

I imagine it could work something like this:

# settings.py
JS_REVERSE_EXCLUDE_NAMESPACES = ["staff_only", ]

# In main_site.urls.py
urlpatterns = patterns('',
    url(r'^jsreverse.json$', 'django_js_reverse.views.urls_json', name='js_reverse'),
)

# In staff_only.urls.py
app_name = 'staff_only'
urlpatterns = patterns('',
    url(r'^jsreverse.json$', 'django_js_reverse.views.urls_json', {"exclude_namespace":[]}, name='js_reverse'),
)

When no options are specified for a particular view, settings are used as a fallback. This would provide a variety of strategies that could be used. Critically, it wouldn't change the way things work at the moment, so there will be no backwards compatibility issues.

Similar options could be added to the template tag and management command.

Moving forward

Taking a quick look at the code, I don't think it would require too much actual change. I think the bulk of the work would be writing the docs and tests.

@ierror @graingert Do you have any thoughts about this?

I am happy to put in the work to make this happen, but I'd appreciate some kind of indication that such a PR would in principle be acceptable before starting work on it.