On Apr 5, 2007, at 1:50 PM, Max Ischenko wrote:

> Alberto,
>
> On 4/5/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
> > def test_options():
> >     w = MultipleSelectField(options="Group1 Group2 Group3".split())
> >     eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1']))
> >     print w.validate(['GroupX'])
> >     assert 0, "formencode.Invalid not raised"
> >
> > I was assuming that the select widget will only accept options that
> > are in the options list. No?
>
> This is a tricky case. For that test to pass a OneOf valiadator is
> needed, however, that would break the callable support for the
> "options" parameter since the validator is fixed at construction
> time. I can think of 2 ways to solve it:
>
> 1) avoid using a callable for "options" and pass a OneOf validator
> explicitly
>
> That's hardly an option (sorry for pun) -- callable are invaluable  
> in certain situations.

I know. I was refering to avoiding callabes only when you absolutely  
need a OneOf validator (hence know needed options before-hand when  
instantiating the widget).

Another solution would be to create the form instance dynamically in  
every request, however, this would "break" TG's way of validating  
through the validate decorator since it needs the form instance at  
class or module scope (or do some dirty hacks with the callable you  
can pass it to provide the form instance). This could be solved by  
validating inside the controller with an equivalent form (twForms  
doesn't check on form identity like TG widgets do so different but  
equivalent form instances can work)

>
> 2) Use a hidden field to store view state and make validators aware
> of it to validate accordingly.
>
> What's a "view state"?
>
> By design, widgets are static: you can create one as a module  
> global and keep using it for the program's lifetime.
>
> OTOH, to validate with OneOf you need to know which options were  
> actually used to render the form last time and this information has  
> to be kept somewhere. You can pickle and sign this into a bundle  
> and put as a hidden field on a form. Is it what you means?

Exactly

>
> It may be not very elegant but I don't see a better way. You can  
> also save options temporarily in the the widget itself and passing  
> some bucket-id as a hidden. This can also work as long as widgets  
> does it in a thread safe way.

I've heard ASP does something similar. I don't thiink that saving  
options temporarily in the widget is a viable solution because they  
have to survive across requests. How could we handle that?

Alberto

P.S: lets move this thread to toscawidgets-discuss please :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to