Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#3941 closed (invalid)

tutorial 3 decoupling example seems dubious

Reported by: pscott@… Owned by: Jacob
Component: Documentation Version: dev
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

At the end of part 3 of the tutorial, in the section "Decoupling the URLconfs", there's a line that says:

"Now that polls are in their own URLconf, they can be placed under “/polls/”, or under “/fun_polls/”, or under “/content/polls/”, or any other URL root, and the app will still work."

But in the code example, there's still a "mysite.polls.views" as the first argument to patterns(). That doesn't seem especially relocatable. An explanation of some kind would probably be useful.

Change History (2)

comment:1 by James Bennett, 18 years ago

Resolution: invalid
Status: newclosed

A URLConf and the views it routes to are always "coupled" in the sense that a URL cannot say "oh, no particular view". But in the sense that the views of the polls app can now be dropped anywhere in the project's URL structure, they are "decoupled".

comment:2 by pscott@…, 18 years ago

Ahh, okay, I think I understand why this is confusing now. There's two different "decouplings" that are talked about in this section which are kind of muddled together:

"Django apps are meant to be pluggable — that is, each particular app should be transferrable to another Django installation with minimal fuss."

"The idea behind include() and URLconf decoupling is to make it easy to plug-and-play URLs."

The first couple paragraphs seem to imply that the section is going to be about the former, and it is a little bit. The app-specific stuff gets pulled out of the global urls.py and into an app-specific one. But by the end it looks like the main point of the section was to make it so you could switch the url root around easily, not make the app itself (or at least the part we were looking at) totally encapsulated/relocatable. I certainly don't know the framework very well, and it may be that you can't really do anything to specify the views you're dispatching to in any sort of relative way, but that's where I as a naive new user reading this tutorial was expecting this was going to go. (I was half expecting some python 2.5 ".." notation or something.)

Anyway, not saying there are any actual errors here, just providing my criticisms as requested by the documentation footer. :)

Note: See TracTickets for help on using tickets.
Back to Top