Well, I still see that policy a way of hiding symptoms, more than an advantage for users, but thank you so much for the explanations Russell.
On Jan 15, 4:52 pm, Russell Keith-Magee <[email protected]> wrote: > 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.
