I've posted one reply already, not sure if its waiting for moderation or it got lost somehow.
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, I had no custom validators. > 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. Thanks a lot for the good explanation and pointing me in the right direction. By looking at value_at_request, I've found out that the issue is with the values for selectboxes being stored as strings in there. Doing: pylons.tmpl_context.widget.__widget__.value_at_request['type'] = int(pylons.tmpl_context.widget.__widget__.value_at_request['type']) right before rendering the template would fix it. A more proper solution that fixes it too is setting: validator = validators.Int() inside my selectbox widget. Am I supposed to need this, however? I thought these simple validators are picked automatically based on the information from the model (it works like that with requred fields for me). If it is needed, it should probably be documented somewhere, I've wasted far too much time finding out what's wrong... -- 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.
