Jacob Kaplan-Moss wrote: > > >> We'll have to think about how to fit the template debugging work I did >> in new-admin into this as well > > > Ooh, this is nice -- I hadn't seen it before. I'll take a look at your > code and think about how the two could work together, but to keep SVN > conflicts to a minimum I won't actually integrate anything into the > trunk. At first glance it looks like the best thing to do would be to > make the attributes needed to render this exception into fields on a > TemplateError exception which the top-level error handler would notice > and treat differently than other error types.
A 'source' attribute gets added to the TemplateSyntaxError. This is a tuple of (origin, (start,end) ). origin is an object that knows how to reload the template, and (start, end) are character offsets into the template(where the error occured). You can see how you use this in django/middleware/template_debug.py And the implementation is in: django/core/template/[__init__,loader].py At the moment it throws away any bits of stack trace above the rendering of a template tag. >> One thing I haven't come up with a satisfactory answer to is where to >> put the template for this, and what it should look like - at the moment >> it is in the admin app, and uses that layout too. >> >> Maybe we need a "last chance" template loader that will always be added >> on the end of TEMPLATE_LOADERS? > > > Since these error pages need to be available when other things may be > broken -- even badly -- I'm routing around TEMPLATE_LOADERS and loading > the template files directly using Template(). This means that you > don't get to override them, but since they're error pages that are only > seen when DEBUG == True I don't see that that's a biggie. > > Either way, I'm going to make a few tweaks and check this in later > today; feel free to critique my code :) > > Jacob > So where are the files located?
