newforms widget idea
Hi all,
the select-form-widget and the selectmultiple-form-widget display's a
choices-list as
...
...
From the per-row-level-permision branch there is an alternative issue to do
something like this:
...
...
I made 2 new widgets, selectgrouped and selectmultiplegrouped, which would
resolve such an issue. The optgroup is inserted into choices like a normal
option: choices= ( ['__group__', 'label for group'], ['value1', 'label1'])
I added a simple example into the regression tests.
I would be also possible to merge the select/selectgrouped widget into one
widget, which I would prefer to be the best solution.
Regards,
Dirk
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: django/newforms/widgets.py
===
--- django/newforms/widgets.py (Revision 4293)
+++ django/newforms/widgets.py (Arbeitskopie)
@@ -134,6 +134,28 @@
output.append(u'')
return u'\n'.join(output)
+class SelectGrouped(Select):
+def render(self, name, value, attrs=None, choices=()):
+in_optgroup = False
+if value is None: value = ''
+final_attrs = self.build_attrs(attrs, name=name)
+output = [u'' % flatatt(final_attrs)]
+str_value = smart_unicode(value) # Normalize to string.
+for option_value, option_label in chain(self.choices, choices):
+option_value = smart_unicode(option_value)
+if option_value == u'__group__':
+if in_optgroup:
+output.append(u'')
+output.append(u'' % escape(smart_unicode(option_label)))
+in_optgroup = True
+continue
+selected_html = (option_value == str_value) and u' selected="selected"' or ''
+output.append(u'%s' % (escape(option_value), selected_html, escape(smart_unicode(option_label
+if in_optgroup:
+output.append(u'')
+output.append(u'')
+return u'\n'.join(output)
+
class SelectMultiple(Widget):
def __init__(self, attrs=None, choices=()):
# choices can be any iterable
@@ -157,6 +179,28 @@
return data.getlist(name)
return data.get(name, None)
+class SelectMultipleGrouped(SelectMultiple):
+def render(self, name, value, attrs=None, choices=()):
+in_optgroup = False
+if value is None: value = []
+final_attrs = self.build_attrs(attrs, name=name)
+output = [u'' % flatatt(final_attrs)]
+str_values = set([smart_unicode(v) for v in value]) # Normalize to strings.
+for option_value, option_label in chain(self.choices, choices):
+option_value = smart_unicode(option_value)
+if option_value == u'__group__':
+if in_optgroup:
+output.append(u'')
+output.append(u'' % escape(smart_unicode(option_label)))
+in_optgroup = True
+continue
+selected_html = (option_value in str_values) and ' selected="selected"' or ''
+output.append(u'%s' % (escape(option_value), selected_html, escape(smart_unicode(option_label
+if in_optgroup:
+output.append(u'')
+output.append(u'')
+return u'\n'.join(output)
+
class RadioInput(StrAndUnicode):
"An object used by RadioFieldRenderer that represents a single ."
def __init__(self, name, value, attrs, choice, index):
Index: tests/regressiontests/forms/tests.py
===
--- tests/regressiontests/forms/tests.py (Revision 4293)
+++ tests/regressiontests/forms/tests.py (Arbeitskopie)
@@ -3,6 +3,7 @@
>>> from django.newforms import *
>>> import datetime
>>> import re
+>>> from django.newforms.widgets import SelectGrouped, SelectMultipleGrouped
###
# Widgets #
@@ -31,6 +32,31 @@
>>> w.render('email', 'Å ÄÄÅœÄÅŸÅ¡Ä', attrs={'class': 'fun'})
u''
+### SelectGrouped Widget
+
+>>> choices = []
+>>> choices.append(['__group__', 'label for group 1'])
+>>> choices.append(['value1', 'label1'])
+>>> choices.append(['value2', 'label2'])
+>>> choices.append(['__group__', 'label for group 2'])
+>>> choices.append(['value3', 'label3'])
+>>> choices.append(['value4', 'label4'])
+>>> w = SelectGrouped(choices=choices)
+>>> w.render('name','value1')
+u'\n\nlabel1\nlabel2\n\n\nlabel3\nlabel4\n\n'
+
+### SelectMultipleGrouped Widget
Re: New newforms code
Honza Král wrote: On 1/6/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote: well, the problem I see here is that you move the responsibility to programmer, if designer wishes to change the output, he would have to go to python... Producing HTML is Python is the root of the problem. Most of HTML widget libraries out there use template pieces to produce form output - one template per widget. Have you had any though to move this kind of solution? I already once hacked oldforms a bit to provide me TemplateWidget. Or do you feel this kind of solution would be "core enough" for Django? It could be easily done with one master widget template which would be extended by per-class widget templates. The user could easily override the master template for site specific customizations. this is a very nice work, but again I feel like it is unnecessary and sometimes promotes bad habits, for example validation should take place IN the form - otherwise you defy its purpose to do that you simply override the clean() method or you add clean_FIELD() to validate individual fields... Ah. I was not aware of clean_FIELD() possibility. I am not sure whether is what documented yet so I have missed it. This sounds great! also hacking into a form instance via form.data and form.is_bound directly seems wrong - it is not part of the published interface and can change... Yes, that's a stop gap solution. I hope BaseForm would provide more hooks for custom implementations. looks like a lot less work then subclassing your FormHandler and working with that... its so little typing that its almost not worth writing a wrapper around that - the wrapper (in order to be useful) would have to have so many options that it would be much more complicated that this straightforward code, which gives you way more flexibility... Ok. I'll see what direction newforms begins to evolve. I'll try to develop FormHandler by then through real world use cases. Also, I can maintain it as a separate downloadble product. Great work guys! Cheers, Mikko --~--~-~--~~~---~--~~ 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 widget idea
On 1/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi all, the select-form-widget and the selectmultiple-form-widget display's a choices-list as ... ... From the per-row-level-permision branch there is an alternative issue to do something like this: ... ... I made 2 new widgets, selectgrouped and selectmultiplegrouped, which would resolve such an issue. The optgroup is inserted into choices like a normal option: choices= ( ['__group__', 'label for group'], ['value1', 'label1']) I added a simple example into the regression tests. I would be also possible to merge the select/selectgrouped widget into one widget, which I would prefer to be the best solution. in this case you would have to add a custom validation saying that __group__ is not allowed, even though it's listed in choices... would it be acceptible to have different 'choices' layout? for example: choices =( ... ( 'Group_name1', [(1, 'one'), (2,'two'), ]), ... ( 'Group_name2', [(3, 'three'), (2,'four'), ]), ... ) # simpler render method output = '\n %s\n' % '\n '.join( [ ... '\n%s\n ' % ... ( gr_label, '\n'.join( [ ... u'%s' % ( value, (value == 'two' and ' selected="selected" ' or ''), label ) for label, value in gr_list ... ] ) ) for gr_label, gr_list in choices ... ] ) print output 1 2 3 2 this would mean incopatibility with Select and SelectMultiple, but on the other hand no special magic like '__group__' I do not feel strongly one way or the other, just offering another option... Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > -- Honza Kr l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Search API branch status?
I was wondering whether I could just grab django/contrib/search, and now I know. Thanks! I'll give that a shot. Given that workaround, I wouldn't worry about a downmerge right now, I know how time-consuming they are. TK --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Newsforms: submit patches?
I am fairly new to python and also to django, so please forgive me any missteps: I made two patches in newforms.models part of django (one is taking field.editable in account, the other fixes the create-function so it maps the data coming from the form to the corresponding db-columns) The question now: is it of any use to post patches concering newforms as it is currently under massive development? --~--~-~--~~~---~--~~ 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: New newforms code
Mikko Ohtamaa wrote: Producing HTML is Python is the root of the problem. Most of HTML widget libraries out there use template pieces to produce form output - one template per widget. Have you had any though to move this kind of solution? I already once hacked oldforms a bit to provide me TemplateWidget. Or do you feel this kind of solution would be "core enough" for Django? I just wanted to say that this is the reason I'm reluctant to use Django's forms (new or old) no matter how stable it is. I like that any major chunk of HTML code is visible for tinkering in my template files. Maybe a template solution would be more work (probably some repetition, I haven't really thought about how to combine both some automation and custom template files), but it would also be less surprising for me. -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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: Newsforms: submit patches?
On 1/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I made two patches in newforms.models part of django (one is taking field.editable in account, the other fixes the create-function so it maps the data coming from the form to the corresponding db-columns) The question now: is it of any use to post patches concering newforms as it is currently under massive development? Hi Philipp, Yes, it would certainly be useful if you posted those patches! I'm excited to see them and work to integrate them. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: Newsforms: submit patches?
Ok, I'll post the patches. One further question: db.models.fields.TextField.formfield() currently returns a CharField witout its widget set. I would have expected its widget set to widgets.Textarea. Is this by design? greets Philipp On Sun, Jan 07, 2007 at 01:15:41PM -0600, Adrian Holovaty wrote: On 1/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >I made two patches in newforms.models part of django (one is taking >field.editable in account, the other fixes the create-function so it >maps the data coming from the form to the corresponding db-columns) > >The question now: is it of any use to post patches concering newforms >as it is currently under massive development? Hi Philipp, Yes, it would certainly be useful if you posted those patches! I'm excited to see them and work to integrate them. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com > --~--~-~--~~~---~--~~ 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: Newsforms: submit patches?
On 1/7/07, Philipp Keller <[EMAIL PROTECTED]> wrote: One further question: db.models.fields.TextField.formfield() currently returns a CharField witout its widget set. I would have expected its widget set to widgets.Textarea. Is this by design? No, that's not by design -- it just hasn't been done yet. That's a good example of why we need solid contributors like you. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms: Choices don't accept unicode values
Hi, not sure but i think there is a bug in a fields choices with python 2.3 When i do something like http://dpaste.com/hold/4454/ i get an UnicodeDecodeError when rendering the form to html. A friend of mine tested it with python 2.4 without a problem. -johannes --~--~-~--~~~---~--~~ 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: Choices don't accept unicode values
On 1/7/07, jfroehlich <[EMAIL PROTECTED]> wrote: Hi, not sure but i think there is a bug in a fields choices with python 2.3 When i do something like http://dpaste.com/hold/4454/ i get an UnicodeDecodeError when rendering the form to html. A friend of mine tested it with python 2.4 without a problem. Hi Johannes, Thanks for reporting this. I've verified the UnicodeDecode error in Python 2.3.5, and your friend is correct -- it worked properly for me in 2.4.3. I'll investigate... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#3250 - Patch to add missing RequiredIfOtherFieldsNotGiven and two supporting validators
Hi, http://code.djangoproject.com/ticket/3250 This adds the RequiredIfOtherFieldsNotGiven validator documented at http://www.djangoproject.com/documentation/forms/#validators but missing from trunk. It also adds two supporting validators: RequiredIfAllOtherFieldsNotGiven and AllValidators, semantics documented in that ticket. -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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: Multipart message capability
On 1/4/07, Suriya <[EMAIL PROTECTED]> wrote: Russell Keith-Magee wrote: > > Read the thread on the ticket - Jacob has stated what is standing > between the ticket and acceptance - documentation of the feature. > > Write some documentation (or at least get an intitial draft ready), > add it to the patch, and we can get this feature into the trunk. That was written a long time ago. The new patches contain changes to doc/email.txt as well. Ah - sorry - I didn't register that the second two patches were new, so I recycled a response from when the same question was asked a month ago. The new patches deviate from the original patches that were tacitly accepted by Jacob; in addition, there new patches provide two competing implementations, making a total of three. Personally, I favour the original approach to the newer versions. There is probably some room for a helper function that implements the magic-typing behaviour of the second patch, but I'm hesitant to encode that sort of magic as a fundamental part of the system. However, I'm willing to be convinced otherwise, and I won't commit anything until there has been at least _some_ discussion on the subject. Feel free to start and lead the discussion (if this reply doesn't provoke any comments). One quick comment on the new patches - the documentation examples don't close the file handles. This is a habit that shouldn't be encouraged. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
