On Thu, Jan 7, 2010 at 2:54 AM, Rick van Hattem <rick.van.hat...@fawo.nl> wrote: > Hi, > > Maybe this question has already been asked, but I am wondering why Jinja2 > compatibility can't be fixed in a clean way. Currently the code assumes that > if an exception has a "source" attribute that it's a Django exception and can > be processed as such. (the code: > http://code.djangoproject.com/browser/django/trunk/django/views/debug.py#L87 )
There is an important difference between "can't" and "hasn't". The Django core's development priority is Django, and Django is a 'batteries included' framework. As a result, our development priority is in making Django's template language better. We are open to making any changes that make it easier to plug in different template engines or ORMs (or any other external component). We (the core) just haven't spent a lot of development time trying to reach that particular goal. If someone in the community wants to pursue this goal, they are welcome to do so. Propose a patch, and as long as it doesn't fundamentally compromise the design of Django, it stands a good chance of getting into trunk. > However, if all template exceptions have the same base exception (as they > logically should) wouldn't it automatically work if you simply test for the > exception? No, it wouldn't (at least, not completely). Jinja wouldn't extend Django's TemplateSyntaxError class, so using the approach you describe, Jinja's TemplateSyntaxErrors wouldn't break the debug page, but you wouldn't get good template error feedback either. > There has been a previous ticket with a hacky solution: > http://code.djangoproject.com/ticket/10216 > > But I feel that testing for specific exceptions (as any try/except should) > would make the code cleaner and fix this problem. Assuming that any exception > with a source attribute can be processed as the expected Django exception is > simply wrong. I disagree. Checking for capabilities rather than types is the cornerstone of duck typing. In this case, Jinja's TemplateSyntaxError doesn't quack in quite the same way as Django's duck. I can see three possible solutions: 1) The capability check isn't rigorous enough. Modify the capability check to make it more specific. 2) Push the problem back to Jinja. As Malcolm's comment on #10216 notes, Django has a protocol for template errors and doesn't make any claim to having Jinja compatibility. If Jinja makes claims to Django compatibility but doesn't adhere to that protocol, then it's up to Jinja to fix the problem. 3) Come up with a new capability that can be used instead. >From a cursory inspection, I'm not sure there is much we can do with (1) - there isn't a lot of detail on Exception that can be used for a capability check, and the only attribute that is actually needed is 'source' (albeit in a particular format that evidently Jinja doesn't use). (2) isn't Django's problem to fix. (3) Seems like the most promising option. For example, most of the call to ExceptionReporter .get_template_exception_info() could be deferred to the exception itself. If we refactored that code into a method on the exception itself, we could use that method as the capability that we check for. It would be less ambiguous (not many exceptions would have a 'get_template_exception_info' method), and it would allow *any* exception (template or otherwise) to raise an embedded exception that provided template details on the technical 500 page. However, as I said originally - the existing setup works for Django at present. If you want to improve support for Jinja... patches are accepted :-) Yours Russ Magee %-)
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
