Robin Haswell wrote:
> > Hi Matt,
> >
> > Thanks for pointing this out, your right indeed!
> > I forgot that a dict doesn't preserve the order (sorry guys) (any news
> > in the python world regarding this? I can't see how maintaining the
> > order could ever hurt, while mixing it sometimes hurts, WidgetsList...
> > :-().
> >
> > Your hybrid solution looks good but probably requires too much
> > verbosity, for today I'm stopping here, let's see what other thinks, to
> > recap:
> >
> > 1) My solution n°1
> >
> > 2) Matt solution
> >
> > vote please! ;-)
> >
> > Ciao
> > Michele
>
> Hey Michele, thanks for looking in to this. I was just about to cross "Open
> ticket on optgroups" on
> my todo list when I noticed that it seems a bit redundant now. Can I add my
> $0.02 on this?
>
> Regarding SingleSelectField vs SingleSelectFieldWithOptgroups, I think this
> is unnecessary as the
> format of the parameter is going to make this rather obvious, and the two
> aren't necessarily exclusive.
>
> I propose the solution of:
>
> [
> (None, ["Please choose an option"]),
> ('Dynamic Languages',
> [(1, "Python"), (2, "Ruby")]
> ),
> ('Others',
> [(3, "Java"), (4, "C++")]
> ),
> ]
>
> This gives us the advantage of allowing us to `zip` two lists - a list of
> optgroups and a list of
> options:
>
> optgroups = [None, "Dynamic Languages", "Others"]
> options = [
> ["Please choose an option"],
> [(1, "Python"), (2, "Ruby")],
> [(3, "Java"), (4, "C++")]
> ]
> select_options = zip(optgroups, options)
>
> >>> print select_options
> [(None, ['Please choose an option']), ('Dynamic Languages', [(1, 'Python'),
> (2, 'Ruby')]),
> ('Others', [(3, 'Java'), (4, 'C++')])]
> >>>
>
> I think my solution is more semantically accurate (and easier to generate the
> structure)3 than the
> equivalent dict option, however differentiating between what is supposed to
> be a regular single
> select field and what is supposed to have optgroups might be a bit messy:
>
> for value, option in options:
> if type(option) is list:
> # optgroup code
> pass
> else:
> # just show an <option/>
> pass
>
> However, this allows us to simplify our case of when we don't want an
> optgroup before some optgroups to:
>
> [
> (None, "Please choose an option"), # The second value of this tuple is
> not a list
> ('Dynamic Languages',
> [(1, "Python"), (2, "Ruby")]
> ),
> ('Others',
> [(3, "Java"), (4, "C++")]
> ),
> ]
>
> Of course, if detecting whether we want an optgroup or not is a bit messy, we
> could always have an
> OptGroup widget. I'm not a fan of this plan though as I think more class
> hoop-jumping is bad :-/
>
> Cheers
>
> -Rob
Hi Robin,
Thanks for the feedback, incidentally this is the exact syntax I
ended-up to implement yesterday:
http://tinyurl.com/hpzbj
You will probably find this into 0.9a6 since I'm going to commit it...
;-)
Ciao
Michele
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
