On Jul 8, 11:31 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > [...] but some of Django's own template tags (e.g. `widthratio`) don't > > adhere to > > this policy. > > These are bugs, and should be fixed.
Thanks for this clarification. I will try to review the built-in tags and submit some patches to fix these bugs. For added clarity, should a template tag behave the same when a string or variable is passed as it's argument? E.g. if the first argument to a template tag is expected to be a number, we can validate that and raise a `TemplateSyntaxError` at compile time if it is passed in as a literal, but we can only validate it and fail silently at render time if it is passed in as a template variable. I believe that this behaviour is inconsistent and confusing, and can lead to unexpected and difficult to trace problems. To avoid this, should the validation of arguments to template tags that can be passed in as either literals or template variables be limited to checking that an argument was passed, and delay type or value checking until render time, which will always fail silently? > I'm against this, for a whole host of reasons — the crux of which > comes down to the philosophy that templates are *not* a programming > language, and introducing a try/except concept into them is about > seven steps too far. > > The point of the template language is to give front end designers and > developers the space to explore without the persnicketiness a > so-called "real" programming language introduces. What you're asking > for here is to fundamentally change the philosophy of the template > language. If you disagree that fundamentally with the ideas behind the > template language I really think you'll be better off finding another > one than trying to swim upstream. I agree that what I suggested would be a fundamental change, and not likely to be adopted in full. However, I would still like to hear other ideas from the community about smaller steps that we could take that would make exception handling more consistent and selective, without changing the fundamental philosophy of the template language. Firstly, Jonathan Slenders makes the point that perhaps not ALL exceptions should be silenced. Secondly, there is the inconsistent behaviour between production and development environments related to the `TEMPLATE_DEBUG` setting. I think that if an exception is intentionally silenced in production, it should also be intentionally silenced with `TEMPLATE_DEBUG = True`, to allow for consistent behaviour during development. If an exception IS worth raising when `TEMPLATE_DEBUG = True`, it should also raise in production, and these types of exceptions should be caused by an underlying problem in the template tag or the evaluation of an object passed to the template tag, rather than something that a template author is likely to trigger because they are not programmers. Does anybody else have ideas or suggestions about these two issues, or other small improvements we could make to exception handling in templates without fundamentally changing the philosophy of the template language? Cheers. Tai -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
