On Sun, Jul 12, 2009 at 6:17 AM, Tim Chase<django.us...@tim.thechases.com> wrote: > I didn't notice anything in the testing docs[2] that warns about > this, and the tutorial adds django.contrib.admin but elides the > detail that omitting the admin (described as optional[3]) causes > test failure.
I tend to view it a bit differently than you do, it seems. To get at the root of the problem, consider an analogy. Alice writes an application containing a view which, by default, wants a template named 'foo.html'. And Alice writes unit tests which exercise that view. As a result, her unit tests pass only when a template named 'foo.html' is available. Her application does not provide this template, and assumes that you will create it. Bob writes another application. Bob has no knowledge of Alice or of Alice's application (and Alice has no knowledge of Bob or of Bob's application). But for his own purposes, his application ships a template named 'foo.html'. Carol wants to run the unit tests for Alice's application, and discovers that they pass if she has Bob's application installed, but fail otherwise. Would Carol be justified in saying that Alice's tests fail unless Bob's application is installed? Personally, I'd say no: it just happens that Bob's application has a template of the right name, and Carol was overlooking the fact that a functional setup sometimes requires certain templates to exist (and unit tests are perfectly justified in assuming that you have a functional setup -- in fact, they're a good way to find out when you don't). Similarly, contrib.admin -- because it needs to work out-of-the-box without requiring you to create any templates -- supplies templates with the names contrib.auth looks for. But you can just as easily write your own templates with the correct names, and for public-facing authentication functions (i.e., admin, password change, etc. for non-admin users) you are encouraged to do so (and if you do the tests will pass). Perhaps a deeper issue is that not every Django application is required to ship with default templates. Personally, I like that -- making truly generic default templates which can drop into any site and be acceptable is a pipe dream. The admin gets away with it because the admin isn't meant to fit in with the public-facing look and feel of anyone's site. But contrib.auth can't generically do this because you typically do want those views to end up fitting the public-facing look and feel of your site. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
