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.

Reply via email to