David Bernard wrote: > WARN : if you use server side validation, the validation is done against > values > provide during widget's construction (as paramater or through the validator).
I updated my example app to show how you use dynamic options. http://trac.turbogears.org/turbogears/ticket/490 For a single field we should use the validator provided if any (if it's not there I try to add a good default), for multiple field it's wrapped inside a ForEach validator that returns a validate list (you can also pass a list as default at constructor) to you method. I'm not using OneOf since it expects to be inizialized with values and you will not be able to change it dynamically (threadsafety), anyway for these widgets the input value will always be one of the possible choiche so the real use of a validator in that case is just the conversion from/to python, so I can't see any problem. On the other hand I don't except someone so crazy to change a option list to be totally dirrent from the default one. I mean, if you construct with: options = [(1, "python"), (2, "java"), (3, "ruby")] you will probably add or remove some options but not provide a totally different thing like: options = [("cool", "python"), (2, "java"), ("again", "ruby")] that's mixing string and int values, if someone is going to do it I would like to take a look at its controller method. :-) Ciao Michele > > Michele Cella a écrit : > > Kevin Dangoor wrote: > > > >>Hi Lee, > >> > >>This functionality is definitely something we need, in one form or > >>another. I'm hesitant to commit another widget right this moment, > >>because there are some good suggestions for API cleanup ongoing from > >>David Bernard and Michele Cella. Now is really the last chance to do > >>that kind of cleanup. > >> > >>I'd rather not combine the value with the set of options. You should > >>be able to pass another keyword to insert() to hold the options list. > >>And, the main select widget can probably support both styles of > >>working: up-front definition and render-time definition. > > > > > > Yes, that's exactly how I've done it. > > > > Any widgets can provide additional options using a constructor argument > > (options) and the same argument at render/insert time. > > > > For a selection widgets those options are managed as the possible > > choiches. > > > > Ciao > > Michele > > > > > >>Thanks for the patch and ticket... we do need this in some form, > >>without question... (I *think* the current widget may take a callable > >>for the options list, which is the current mechanism for handling > >>this, but that's not always as pleasant.) > >> > >>Kevin > >> > >>On 1/30/06, Lee McFadden <[EMAIL PROTECTED]> wrote: > >> > >>>http://trac.turbogears.org/turbogears/ticket/475 > >>> > >>>Comments and discussion please. I think that this is a good addition > >>>to the base widgets. If not then I'll add it as a recipe for a custom > >>>widget on the wiki. > >>> > >>>(Copied from the ticket) > >>> > >>>Sometimes you don't know what a SelectField's options are going to be > >>>before you .insert() it and changing the options on the fly isn't > >>>threadsafe. > >>> > >>>Attached is a patch with a new widget called DynamicSelectField?. It's > >>>essentially the same as a normal SelectField? except it pulls out it's > >>>options from widget_value on .insert(). > >>> > >>>Examples: > >>> > >>><div> > >>> ${testwidget.insert(value=(3, [(1,"Apple"),(2,"Banana"),(3,"Pear")]))} > >>></div> > >>><div> > >>> ${testwidget.insert(value=(2, [(1,"Audi"),(2,"VW"),(3,"Ford")]))} > >>></div> > >>> > >>>The first argument in the value tuple is the value of the option you > >>>want to be selected and the second is a list of tuples containing the > >>>options and their respective values and text. > >>> > >>>With this method the data can still be passed when the widget is > >>>nested in a Form Widget (or subclass thereof). > >>> > >>> > >>>Lee > >>> > >> > >> > >>-- > >>Kevin Dangoor > >>Author of the Zesty News RSS newsreader > >> > >>email: [EMAIL PROTECTED] > >>company: http://www.BlazingThings.com > >>blog: http://www.BlueSkyOnMars.com > > > > > > > > -------------------------------------------------------------- > David "Dwayne" Bernard Freelance Developer > mailto:[EMAIL PROTECTED] > \|/ http://dwayne.java-fan.com > --o0O @.@ O0o-------------------------------------------------
