| 1 | | '''tl;dr''': |
| 2 | | - +1 for the current feature request |
| 3 | | - make it possible to have a default application namespace everytime |
| 4 | | |
| 5 | | '''Todo''': |
| 6 | | |
| 7 | | - maybe update for master |
| 8 | | - default application namespace everytime |
| 9 | | - more test |
| 10 | | - more documentation |
| 11 | | |
| 12 | | ---- |
| 13 | | |
| 14 | | |
| 15 | | This would be nice and will IMO allow to simplify the url namespace thing while still keeping the mechanics for complex (and a bit weird setups) possible and for most usecases, people will say «Yay! it's actually what I need!». |
| 16 | | |
| 17 | | I did not understand the point of «application_namespace» until I wrote the following paragraph: |
| 18 | | |
| 19 | | Application namespace is useless inside the application itself, since application_ns:index will always resolve to current_app:index in this case, application_ns:index is equivalent to index. There is a case where «index» can be something else when you are inside another application, url patterns of application B, included in url patterns of application A, and have another view named «index», then the only way inside application B to get the index of application A in a *generic way* is to use the application A application namespace. This can be achieve otherwise, and I think that what is still used by people, you namespace the url name of so that you never have the same urls names something like «app-a-index» or «app-b-index» or better use semantic url names instead of generic naming. |
| 20 | | |
| 21 | | Using application namespace outside of the application is weird at best, I did not find a useful usecase for it, except maybe if an application C, is included in a project and expects application A to exists then getting {{{reverse}}} work needs the «default application for application namespace» mechanics and the fallback mechanics. |
| 22 | | |
| 23 | | Basically what OP says and with which I agree, is that most of the time (not to say all the time) the guy or gal writring app.urls knows which application_namespace to use for the application so including it in the urls.py makes sens. I will go further and say that namespace which becomes application_namespace should has a default of the application package name. Like @russellm points Python package names are most of the time unique among Python/Django and happens to be most of the time what we need. Allowing for providing another application_namespace introduce the replaceable application pattern, for instance: to allow the django favorites application market to flourish no one use the same package name (which I think allows for them to all be on PyPi) but they all agree to use the same url names, the first is named «django-kingking-favorites» & «kingking» as package name, it doesn't support ajax, so another application exists which implements the same «url scheme» its package is «princess», it's a drop-in replacement of «kingking». If they both use the default application namespace induced by the package name it will be possible to replace one app by another but it will be more difficult (rebuild the favorite application urls inside the project urls for instance). |
| 24 | | |
| 25 | | We cannot get the application package name right everytime (if the patterns are somewhere inside another package inside the application package) to avoid any complex code (!) I will use the urls.py package name, the author will be able to override this default with namespace variable. |
| 26 | | |
| 27 | | Saying -1 or 0 with the argument «this can be done with namespace url names» is not an argument, getting the «application namespace» feature is already useless given namespaced url names. |
| 28 | | |
| 29 | | I'm not sure about the «namespace» naming, maybe «application_namespace» is better, what do you think ? |
| 30 | | |
| 31 | | Here is a usecase, for overriding the application namespace provided by the application author outside the application: There is a clash between several applications that use the same app namespace, but not the same url name schemes aka. they are not replaceable application this should be done with care since it can break the current app which might be using the application namespace... Like it's said earlier this is unlikely to happen. |
| | 1 | **deleted** |