On Thu, 30 Mar 2006 19:49:20 -0000 "Michele Cella" <[EMAIL PROTECTED]> wrote:
>
> Hi Jason,
>
> I don't quite get how your update_options is supposed to work (is it
> called by options_for?) anyway that's how I will go to do what you're
> trying to do:
I use update_options in update_data. It's essentially what you
explained with css_classes, except that it works for any attribute
on any widget. It's a way to add/edit tg_options when all you have
is a widget and something you want passed to the widget at display time.
> Build a css_classes (maybe nested) dict by walking the error one and
> replace all errors key values with the css class you need, then add
> that one to the d["tg_options"] dict inside update_data, this should
> do the trick.
I never thought about just overriding the css_classes. I was just
setting {attrs: {widget: {class: blah}}}.
> Try that and let me know, if it works (and it should I hope ;-)) I'm
> going to change tg_options to something more descriptive that enforces
> the relationship with options_for, for example member_widgets_options
> is good IMHO since we are already using member_widgets.
I'll give it a shot today.
I thought tg_options was a good name. Because options aren't
necesarrily for the member_widgets, things like method and action are
options for the form.
Jason
signature.asc
Description: PGP signature
