Am 12.03.2011 um 22:42 schrieb lukash:
Hi all,
I've just spent a good portion of the day trying to figure out this
issue.
I have a sprox EditableForm (inherited, with no special settings,
__base_widget_type__ is ListForm). I have a standard RestController
with edit(...) and put(...) methods. The put(...) has a
@validate(form=edit_form, error_handler=edit) decorator. I'm
displaying it in the template the standard way calling
tmpl_context.widget(value = value) (setting both widet and value
myself in edit(...)).
When there is a validation error, the form gets displayed with the
error messages. The text fields are correctly displaying the the
content that was in the form before posting it, but the selectboxes
are getting displayed with no value set. Not even the one that is
currently stored in the database.
By logging inside the DecoratedController code I've found out that the
values used to fill the widget are not taken from the value dict I'm
passing it. I don't see this in the documentation. By crawling through
the code I've discovered tmpl_context.form_values being set inside
DecoratedController. This is not used either. I logged all the
variables right before the template is rendered, tried to set dummy
values, its just not being used. I tried to render the widget in the
same spot and log the output, it had the wrong values.
It seems the validation code is being run once again inside the
widget? But even if it is, it is supposed to use the values I sent it,
and it is not doing so. I am clueless. The ToscaWidgets code is
complicated as hell and I wasn't even able to find the place where the
values are set. What is happening in there? And what's the thing with
the validation code being all over the place? It is in the
DecoratedController, there is some code in sprox, even more in
ToscaWidgets and tg.crud seems to have some of its own too. I don't
wanna spend a week studying the source code.
The values are stored in a thread-local object keyed by the widget -
by tw.forms.
It's called value_at_request, and you can find it like this:
my_form_widget.value_at_request
And it's actually a feature that tw ignores the values you pass in,
once there is something in the request - otherwise, you'd overwrite
the data the user has entered! So, if you must, you can clear the
my_form_widget.value_at_request, or override single keys. But you
shouldn't need that, if everything is working correct.
Are the validators you use by any chance self-written? That could
explain the select-box-behavior.
The various validator-invokations have a simple reason: HTTP-variables
are always strings. But the whole purpose of validation is to allow
you to forget about that, and work with e.g. ints, or even database-
objects.
So in case of e.g. select-fields, the option-lists are entities. But
to display them, you need to convert them to strings. OTOH, when
matching the passed value to the one selected, you need to un-convert
them.
Thus the various invocations of the validators.
And debugging... use "import pdb; pdb.set_trace()" to set breakpoints
where you need them.
tw is complex. tw.forms even more so. But usually, they do what you
ask them.
--
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?hl=en.
