I ran through the scenario again and did not see a 2nd http get to
'edit' upon validation failure. I can verify that 'edit' was indeed
called though.
I had the following line generating logs in 'edit'
log.info("####### edit called!, params is %r" %request.params)
And the following log was generated from the 2nd call to get :-
####### edit called!, params is UnicodeMultiDict([])
perhaps the specific validate options on save have caused this strange
behaviour?. Anyhow I will follow the other suggestions on the correct
usage of validate to remove all contradictions just to figure out what
is going on.
Ultimately I will go with Mikes suggestion to inline the validation
which gives me more control.
thanks,
On Jun 26, 1:24 pm, Mike Orr <[email protected]> wrote:
> On Wed, Jun 24, 2009 at 9:08 AM, 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?
>
> @validate gets its data from the request object (called
> self._py_object.request in pylons.decorators.validate(), in the
> dynamic function 'wrapper'). If 'edit' is called, it is indeed a
> method call within 'wrapper'.
>
> So I don't know why request.params would not still contain the data in
> 'edit'. I have also not heard of anybody regenerating a form with
> different settings than the user submitted, so it's possible that's an
> untested area. Also, 'wrapper' calls htmlfill after 'edit' is called,
> which may affect things.
>
> @validate is due for a rewrite because it's not flexible enough, and
> it's too difficult to use parts of it without buying into its whole
> process. There's a ticket open for
> ithttp://pylonshq.com/project/pylonshq/ticket/405
> you can add any features you'd like to see to the ticket.
>
> In the meantime, I'd also consider inlining the validation code rather
> than using @validate. That way you have full control over it.
> Essentially you'd have to recreate the 'try: validate, except Invalid:
> return self.edit()' pattern. You may also want to consider a separate
> method to regenerate a failed form, so that 'edit' isn't trying to do
> too many different things depending on the situation.
>
> --
> Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
