Re: newforms-admin fieldsets classes question
The problem is that the intent is a test like
"bar" in "foo bar baz"
which is true; unfortunately, so is
"bar" in "disbarment"
which shouldn't be (in this context anyway). Thus you should test
"bar" in ("foo","bar","baz")
instead, which seems to be the intent behind this change in the first
place.
I'll file a bug.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: newforms-admin fieldsets classes question
On 11/11/07, Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > IMHo it makes sense to usee a tuple there. I'd go so far as to > recommend *not* to concatenate that (three lines down...); the > subsequent test in line 81 will cause false positives otherwise. ? I don't see how false positives will arise on line 81 here: http://code.djangoproject.com/browser/django/branches/newforms-admin/django/contrib/admin/options.py#L72 as the code is now written? I'm not planning to open a ticket to change code in this area (opted for updating the wiki instead), so if there is a problem it's likely to be forgotten unless you open one. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin fieldsets classes question
On 11/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > On 11/10/07, Karen Tracey <[EMAIL PROTECTED]> wrote: > > Was it intended to change the type of the 'classes' value in an Admin > field > > (now fieldset in newforms-admin) specification from string to tuple? > > > > Yes, it was intentional, but I don't feel particularly strong about > the change. I don't think that backwards compatibility is a good > reason to keep it the same as so many other things are changing > anyhow. That said, it should be documented on the newforms-admin wiki > page, and I apologize for not doing so. Would you mind updating the > wiki or starting a thread on the dev list if you'd like to see the > change reversed? I don't feel strongly about it one way or the other. The quiet nature of the failure bothers me a little, but as you say, so much else is changing that people are going to have to be reading the doc to do the migration, so as long as it is noted there most people won't get tripped up by it. So I'll update the wiki page. Thanks, Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin fieldsets classes question
IMHo it makes sense to usee a tuple there. I'd go so far as to recommend *not* to concatenate that (three lines down...); the subsequent test in line 81 will cause false positives otherwise. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin fieldsets classes question
On 11/10/07, Karen Tracey <[EMAIL PROTECTED]> wrote: > Was it intended to change the type of the 'classes' value in an Admin field > (now fieldset in newforms-admin) specification from string to tuple? The > old doc here: > > http://www.djangoproject.com/documentation/model-api/#classes > > states the value should be a string and if you want to specify more than one > class separate them with spaces. The new code here: > > http://code.djangoproject.com/browser/django/branches/newforms-admin/django/contrib/admin/options.py#L72 > > is clearly expecting a tuple, not a string. You can pass a string in, but > the effect of the init code is to insert spaces between all the characters, > resulting in a quiet failure to do anything useful with an old-style spec. > The change in type means you cannot just cut-and-paste your old fields > specifications (simply renamed to fieldsets) from your old code to the new > way when migrating to newforms-admin. I don't see mention of this backwards > incompatibility on the newforms-admin branch page, so I am wondering if it > was a mistake? Basically I'm wondering if I should change my code to > specify a tuple or open a ticket and supply a patch to newforms-admin to > make it accept strings here ala old admin? Yes, it was intentional, but I don't feel particularly strong about the change. I don't think that backwards compatibility is a good reason to keep it the same as so many other things are changing anyhow. That said, it should be documented on the newforms-admin wiki page, and I apologize for not doing so. Would you mind updating the wiki or starting a thread on the dev list if you'd like to see the change reversed? Thanks, Joseph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
newforms-admin fieldsets classes question
Was it intended to change the type of the 'classes' value in an Admin field (now fieldset in newforms-admin) specification from string to tuple? The old doc here: http://www.djangoproject.com/documentation/model-api/#classes states the value should be a string and if you want to specify more than one class separate them with spaces. The new code here: http://code.djangoproject.com/browser/django/branches/newforms-admin/django/contrib/admin/options.py#L72 is clearly expecting a tuple, not a string. You can pass a string in, but the effect of the init code is to insert spaces between all the characters, resulting in a quiet failure to do anything useful with an old-style spec. The change in type means you cannot just cut-and-paste your old fields specifications (simply renamed to fieldsets) from your old code to the new way when migrating to newforms-admin. I don't see mention of this backwards incompatibility on the newforms-admin branch page, so I am wondering if it was a mistake? Basically I'm wondering if I should change my code to specify a tuple or open a ticket and supply a patch to newforms-admin to make it accept strings here ala old admin? Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
