Re: svn:ignore for new management package
On 8/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Thanks. I've added a few missing svn:ignore properties, including the > ones you mentioned, in [5993]. Thank you. There's one other directory that should be changed - tests/regressiontests/test_client_regress has an svn:ignore of "__init__.pyc", but actually includes several other files. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: forms and designers
We use this in Satchmo:
Discounts
Discount code {{
form.discount }}
{% if form.discount.errors %}*** {{
form.discount.errors|join:", " }}{% endif %}
Does that give you enough control?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newforms issues
On 5/21/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > #3896 - pass value to field specific clean function [2] > > Grr...don't put two issues in one ticket! > > I'm -1 on the first part because it's an unnecessary backwards > incompatibility change for the most part. It's not like it's a massive > performance improvement in an area that is currently slow. > > Definitely +1 on the second part, though. Removing the first assignment > to self.cleaned_data would make a lot of sense. This change would make things cleaner and obvious (as well as being the best way to fix the bug of cleaned_data having uncleaned values). I personally don't mind changing code and retesting for that purpose, but since many others do I'm +0. But I wanted to point out that the two changes are closely related, and both are needed to fix the bug. Applying the second change without the first would break any code that uses a clean_* method right now, and applying the first without the second would also break code as well as not actually fixing the bug. I am not sure that I didn't miss something obvious, though. If I did, please correct me, I would like to properly understand the proposed change. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changeset [5231] -- do_clean_*() is awkward naming
On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > That was exactly why I didn't change clean_data (my initial "fix" was > just to name it cleaned_data). It's already used in lots of code, so the > impact of change it is larger. Changing the undocumented feature is less > disruptive. Unnecessarily intrusive backwards-incompat changes seem > mean. For me, an AttributeError from clean_data is a much more friendly change than silently ignoring code like: def clean_email(self): """Prevent account hijacking by disallowing duplicate emails.""" --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
