I didnt get any replies. Perhaps my question is not clear enough?. Since the 2nd call to 'edit' (the method generating the original form) made to repopulate the form appears to be a simple method call (and not an actual http get) I guess that answers why the request object wont be populated in this case. The question is how can the actual form submission values be accessed in the 2nd call (to be passed to the template) to ensure that the template can correctly regenerate form elements (e.g. dynamic select options updated by ajax when other form values change like other selection fields) that depend on the actual form submission values following a validation failure?.
Am I making any sense? On Jun 24, 12:08 pm, afrotypa <[email protected]> wrote: > Hi, > > I had a question about how @validate works > > Say you have /controller/edit > > which returns a form in a rendered template whose action is / > controller/save > > As well the save action has an @validate decorator associated with > edits submitted form i.e. :- > > @restrict('POST') > @validate(schema=TestSchema(), form='edit', post_only=False, > on_get=True) > def save(self, id=None): > > If TestSchema fails to validate when @validate kicks in, this results > in edit being called (this looks like a method call not an HTTP get) > to re-generate the form for htmlfill to render with errors. This is > all fine an dandy if the select fields for the re-generated form have > the same options as when the form was initially generated and thus > there is no need to change the forms select field options. > > However if regenerating the form requires a different set of select > options (which are dependent on the current select fields values > submitted in the original request), then the 2nd call to 'edit' will > need access to the request parameters in order to intelligently > regenerate the form. It appears request.params does not contain the > request parameters in this case. I was only able to obtain the current > form values in this case by doing something like this :- > > params=dict(request.environ.get('webob._parsed_post_vars')[0]) > > This however does not look elegant and that variable is not guaranteed > to remain a part of the api in future webob versions. > > Does anyone have an idea about how to handle this issue? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
