On Oct 6, 2006, at 7:48 PM, Jorge Vargas wrote:
> > On 10/6/06, Jason Chu <[EMAIL PROTECTED]> wrote: >> I'll admit it, I'm only now looking into why our app doesn't work >> with >> 1.0b1. But now I'm looking into it more and I've noticed something. >> >> Before 0.9a7 (I believe) the options argument on list widgets >> (SelectField, etc) was allowed to return a generator. Once >> _expand_options was added/modified it tries to look at len(opts) >> (line >> 788 widgets/forms.py). I haven't looked a lot into the code, but >> what >> was the reason for the change? To support options such as ["foo", "bar"] where each item is both the value and the displayed text. http://trac.turbogears.org/turbogears/ticket/979 >> >> I do realize that most option lists aren't usually that long, so >> looping over them more than once isn't usually a big deal. Does this >> mean that generators are officially not supported in the options >> argument of a widget? AFAIK generators where never officially supported. I've investigated a bit and I'm surprised it ever worked as many parts of the code expect lists (for example, _guess_validator tries to index the options) even before _extend_options was introduced. So I'll say no, generators are not supported. The param_doc explicitly states options should be a list. >> I just want to know before I go and change all of our application >> code... >> > could this be the change? > http://trac.turbogears.org/turbogears/changeset/1873 Nope, it's this one: http://trac.turbogears.org/turbogears/changeset/ 1682 ("svn blame" is your friend here ;) ) Alberto --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
