On Mar 13, 3:11 am, "Diez B. Roggisch" <[email protected]> wrote: > 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.
No, there are no explicitly set validators at all now. The only thing I'm overriding is the _my_update_params of the PropertySingleSelectField. And it is working when the value passed to the widget is used, so it shouldn't be a problem. > 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. I initially suspected the type mismatch being the culprit, the values I get from the form are strings and they don't equal the integer ids of the selectbox items. But that problem is apparently addressed. > And debugging... use "import pdb; pdb.set_trace()" to set breakpoints > where you need them. Didn't know about that, thanks! > tw is complex. tw.forms even more so. But usually, they do what you > ask them. Thanks a lot for a good explanation. I will investigate more, I should be able to look in the right place thanks to your help. -- 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.
