Maybe have a management command for manage.py that could do this validation along with any other sanity checks that may be worthwhile.
Doing validation automatically on startup, especially if only done with development server or when DEBUG is True would only serve to hide subtle issues with lazy loaded code that may occur later. There is already enough problems with fact that development server preloads middleware and management commands where as in production WSGI server middleware is only loaded on first request and management commands not loaded at all. This difference results sometimes in peoples code working under the development server, but not on a production hosting mechanism. So wouldn't be keen on seeing more differences between development and production servers added as would potentially just hide more problems that could crop up later. For a discussion on these differences between development server and production, have a read of: http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html Graham On Thursday, January 20, 2011 3:06:53 AM UTC+11, tkolar wrote: > > After discussing this on IRC, I decided that this idea could be > worthwhile, but I thought I'd post it here before creating a ticket > for it. > > Disclaimer: I am using version 1.0, so I can't say whether the > behavior I observed is exactly the same in the dev version. Since > nobody told me that anything had changed on IRC, I'm assuming that it > didn't. > > When passing strings as view names in urlconfs, the corresponding > modules will be loaded when the views are called (and not when the > server starts). > I am a newbie, I am currently building my first web app with django, > and I made the mistake not to define a function inside a view that I > referenced from an urlconf (as a string). > The result was that I got weird and seemingly random errors when I > loaded pages sometimes - but not always, and I thought that I was > dealing with some strange bug. It did occur to me that I might have > messed up my config _somewhere_, but I am pretty sure that it would > have taken me a long time to figure out what was going on if I hadn't > gone on IRC - because I was assuming that the urlconf had to be valid > (if suboptimal), because it didn't fail loudly, and considering to > remove that assumption from my mindset would have taken me a while. > > I think that this issue has potential for tripping up newbies quite > easily. While I was told on IRC that passing strings instead of > modules/functions as views in urlconfs is a bad practice, the tutorial > does this, and I think that it can be expected that many newbies will > imitate that. > > My proposal is to validate urlconfs whenever the server starts, for > example by making the mapping from urlconf to view non-lazy, or by > doing a check (a test import, for instance) for every urlconf. This > would have the added benefit that the validation routine could also > check for other potential sources of bugs (for instance, two url > patterns having the same name). > > I see no reason not to fail if the configuration is broken - the web > app is broken and will have to be fixed anyway. However, I am new to > django, and understand that I might be missing something > implementation-specific. > > Well, thanks for reading :) If I get positive feedback about this, > I'll write a ticket, and at least look into implementing it in some > way. > cheers, > Thomas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
