i18n bug in inlines (failing silently)
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). 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. Thank you, Marc -- 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.
Re: i18n bug in inlines (failing silently)
On Sat, Jan 15, 2011 at 9:14 PM, Marc Garcia 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 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.
Re: Feature suggestion: auto translate verbose names
Hi,
Thanks for the tip... that obviously makes it better since
"verbose_name" is no longer there. Obviously still not perfect, since
every line still repeats itself, but thanks anyway.
Klaas
On Jan 15, 4:16 am, Sergiy Kuzmenko wrote:
> It sounds like the concern here are repetitive and untidy lines with
> lots of "verbose_name" so use of positional arguments may prettify a
> bit field definitions. It is not obvious from documentation (all
> fields are listed alphabetically) but for all except relationship
> fields verbose_name is the first positional argument. So field
> definition from your example may be shortened to this:
>
> class MyModel(models.Model):
> some_field = models.IntegerField(_("Some field"))
> some_other_field = models.IntegerField(_("Some other field"))
>
> Of course, you'd still need to use _ or one its verbose equivalents to
> indicate the field is translatable.
>
> Does this make it a bit better?
>
> Cheers
> SK
--
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.
Re: contrib.sites and multitenancy
After having spoken briefly to Carl and Russell about in irc earlier this week, I created a new ticket that addresses the issues raised in this thread: http://code.djangoproject.com/ticket/15089 Would anyone mind accepting it and giving feedback? -- 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.
Re: i18n bug in inlines (failing silently)
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 wrote: > On Sat, Jan 15, 2011 at 9:14 PM, Marc Garcia 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 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.
Feature request: post_form_save signal
Hello All, I understand that feature requests are supposed to be posted to django- developers, but I had a tentative patch, so I went ahead and opened a ticket as well: http://code.djangoproject.com/ticket/15096 Just repeating the summary posted there: several people (see http://stackoverflow.com/questions/4432385/django-how-to-save-m2m-data-via-post-save signal, http://code.djangoproject.com/ticket/13950, etc) have had trouble with / questions about model post_save signals and m2m fields. Personally, I've got a model where the objects almost never change, but every time one is added, I need to run a (relatively expensive) callback function which depends on the entire collection of related objects. Unfortunately, the model's post_save signal fires before the m2m fields are populated, and it's wasteful to run the callback function after every m2m_changed, since only the last change matters. I propose adding a post_form_save signal to any ModelForm that fires after the form's save_m2m method has been called. That will allow the sort of m2m batch processing that I and the stackoverflow poster above are looking for. This is my first time submitting any sort code or working with trac, so let me know how I can improve my postings in the future. Also, I'd be happy try my hand at writing tests / documentation if this is a feature that you want to implement. - James -- 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.
Re: Feature request: post_form_save signal
On Sun, Jan 16, 2011 at 12:49 PM, James wrote: > Hello All, > > I understand that feature requests are supposed to be posted to django- > developers, but I had a tentative patch, so I went ahead and opened a > ticket as well: http://code.djangoproject.com/ticket/15096 > > Just repeating the summary posted there: several people (see > http://stackoverflow.com/questions/4432385/django-how-to-save-m2m-data-via-post-save > signal, http://code.djangoproject.com/ticket/13950, etc) have had > trouble with / questions about model post_save signals and m2m fields. > Personally, I've got a model where the objects almost never change, > but every time one is added, I need to run a (relatively expensive) > callback function which depends on the entire collection of related > objects. Unfortunately, the model's post_save signal fires before the > m2m fields are populated, and it's wasteful to run the callback > function after every m2m_changed, since only the last change matters. > > I propose adding a post_form_save signal to any ModelForm that fires > after the form's save_m2m method has been called. That will allow the > sort of m2m batch processing that I and the stackoverflow poster above > are looking for. I've just marked the ticket wontfix, for a couple of reasons. Firstly, I'm not wild about the confusion of concerns this signal would entail -- you're proposing a model signal that is issued by the forms library. This sort of thing would be easy to break -- for example, if I programatically create a model with a bunch of related objects, the signal won't fire. If you have a post_save signal, *every* model save will trigger the signal; your proposed signal would only fire on *some* model saves. Secondly, there are some serious limitations to what you describe. You've seem to be proposing this as a "after everything is done" signal, so that you know your model has been created with all the M2M relations that are needed -- but that simply won't be the case. The older ticket you reference (#13950) indicates one place where this won't be true -- the admin -- because formsets are handled independently of the base form. Saving a model actually requires saving 1 form and N formsets, and if you issue the signal after the 1 form has been processed, you'll miss any modifications made during the processing of the N formsets. This is true of the admin specifically, but it's also true of in-view form processing in general. A view may involve the handling of multiple forms and multiple formsets all related to a single model -- issuing a signal at the end of *one* of those forms (or formsets) would give a mistaken impression of the 'complete' status of the transaction. Third, as a project, we have to be wary about adding signals, because there is a computational cost associated with them. If we add a signal, we imposes a cost on everyone that *isn't* using it, as well as providing a utility to everyone that *is* using it. This isn't inherently a reason to discard the idea of adding a signal, but given the limitations I've described in the previous two points, it does provide contributing evidence for why we shouldn't do this -- we'd be incurring a cost on everyone to provide a limited utility to some. Lastly, if you *are* willing to accept the limitations and costs, the signal you propose can already be implemented in user-space: class MyForm(forms.ModelForm): class Meta: model = SomeModel def save(self, *args, **kwargs): instance = super(MyForm, self).save(*args, **kwargs) do_your_m2m_logic(instance) return instance do_your_m2m_logic() could be the code you're intending to attach as a signal, or be code to actually emit a signal. Either way, what you're describing can be implemented as an opt-in when you need it. If you want the signal to be emitted before the model itself is saved, pass in commit=false to the super().save() call, and call instance.save() after the m2m logic has been processed. In summary -- I acknowledge that the 'post-m2m signalling' issue exists. Unfortunately, this is an area of leaky abstraction between the "Object" bit and the "Relational" bit of Django's ORM, and because of that leaky abstraction, reliable "object" behavior such as the 'post-m2m signal' is impossible to implement in a reliable fashion in the general case. > This is my first time submitting any sort code or working with trac, > so let me know how I can improve my postings in the future. Also, I'd > be happy try my hand at writing tests / documentation if this is a > feature that you want to implement. Procedurally, you've done exactly the right thing. A clear Trac entry explaining the problem and giving references to existing discussions, a sample implementation pointing the direction where you're intending to head, a kickstarted Django-dev discussion, and an offer to finish the job. That's about as close to a ideal feature request as you can get. Yours, Russ Magee %-) -- You rece
