Code

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#7442 closed (wontfix)

docs about decoupling urls doesn't decouple all the way

Reported by: siva_ Owned by: nobody
Component: Documentation Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Go here:
http://www.djangoproject.com/documentation/tutorial03/

Look at the bottom where it says:
"Now that we’ve decoupled that, we need to decouple the ‘mysite.polls.urls’ urlconf by removing the leading “polls/” from each line:"

Ok, that's fine, but in order for "polls" app to be decoupled completely from "mysite" project, this line:
urlpatterns = patterns('mysite.polls.views',

has to change to:
urlpatterns = patterns('polls.views',

Attachments (0)

Change History (5)

comment:1 Changed 6 years ago by siva_

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 6 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from new to closed

One can argue endlessly about when a piece of code is or is not completely "decoupled"; in this case, since the application is located inside the project directory (and since there is not a guarantee that the application itself will be directly on the Python path, while the project must be in order for anything to work), I don't see a problem with leaving it as-is.

comment:3 follow-up: Changed 6 years ago by newbie

At the risk of arguing endlessly, I respectfully agree with my fellow Django initiate. If I understand the significance of apps and projects properly, this is not only not decoupled, but it is doubly coupled. If the maintainer of a project has to modify project-level settings to include someone else's application, that's understood, although the fewer modifications necessary, the better. If the maintainer of a project has to modify both the project and the application, that's not so desirable.

Is there some way that patterns() can be made to reference the invoking module without having to identify it by name?

comment:4 in reply to: ↑ 3 Changed 6 years ago by newbie

I don't know what people do out in the real world, since I'm still playing with the tutorial. However, the solution I found to this coupling problem for the tutorial app is as follows:

urlpatterns = patterns(name.replace('urls','views'),

(r'$', 'index'),
(r'
(?P<poll_id>\d+)/$', 'detail'),
(r'(?P<poll_id>\d+)/results/$', 'results'),
(r'
(?P<poll_id>\d+)/vote/$', 'vote'),

)

assuming the string 'urls' doesn't appear in the project name or application name, this seems to work. I guess a regex could be used for a more general solution.

This comes up again when calling reverse() to get the URL for HttpResponseRedirect. My code:

return HttpResponseRedirect(reverse(name + '.results', args=(p.id,)))

I don't know enough about Python to work around the import line at the top of views.py, though. I guess the solution would be to include the application directory in the Python search path, as ubernostrum mentioned, in which case there are simpler fixes than those I copied above. I wonder what the security implications of doing this are.

I'm certainly curious to know how this coupling issue is handled by the Django pros

comment:5 Changed 6 years ago by newbie

whoops. sorry. WikiFormatting mangled my code. that's what the preview button is for, I guess.
I hope you get the idea...

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.