On Sat, Jan 15, 2011 at 9:14 PM, Marc Garcia <[email protected]> wrote: > Hey guys, > > I just detected a bug, that causes inlines to "disappear" if there are > non-ascii characters on the inline data. I'm still working on > detecting what's going on, and I'll fill a bug ticket when having all > the information, but I just wanted to post my opinion on something > related: filing silently in templates. > > I know this has been discussed several times, and Django policy is > still "not letting app break after template changes". But while I > understand that programmers doesn't trust designers, and the > motivation of that policy, I have to say that that the results make it > wrong (of course, in my opinion).
The silent errors policy doesn't exist because of a lack of "trust" in designers. It stems from the philosophy that a template that can be successfully parsed should *always* render. If an error is encountered as part of the rendering process, the safest approach is to fall back to do nothing. The example you give is, in my opinion, a perfect example of why this is a really *good* thing. Inlines evidently have some sort of bug related to accented characters. I don't know what this bug is, but for some reason, a problem exists. Let's say that this code is in the wild. If we show a page with broken inlines to an end-user, we have two options: Firstly, we could render an incomplete inline. The resulting inline may have a broken rendering and look bad; it may give the illusion of working when in fact it doesn't; it may render an error message into the content displayed to the user; or it could raise a 500 error. Alternatively, we render nothing, and hide from the user the fact that an error has taken place. Django has taken the position that the latter is preferable. Rather than expose users to broken content or error messages, we hide the errors, and try to make the user experience as seamless as possible given the circumstances. Now that we have a logging framework baked into Django, there is an argument to be made that template errors that are silently ignored should, in fact, be logged so that developers can do a post-mortem and identify problems. However, that would still be a case of hiding the errors from the end user. Only the developer needs to know about the problem so that they can have their attention drawn to it, and then fix it. > This bug doesn't affect sites that are only available in English, but > I think it can be critical for sites in Spanish, French, Portuguese... > As an example, imagine you have a customer model, available from the > admin, and with its invoices as inlines. So, if your application is in > Spanish, and let's say the reference of one invoice is "Servicios de > programación" (programming services, which in Spanish has an accent), > no inlines will appear on the admin, and some users can think you > didn't issue any invoice to that customer yet. > > I've seen that the error doesn't fail silently if DEBUG_TEMPLATE is > enabled, but IMHO is not enough, at least an independent setting > should be required. Which is the point of DEBUG_TEMPLATE -- to let you discover when your template is failing as a DEBUG activity, rather than as something visible in production. 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 [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.
