On 9/5/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
>
> On 9/5/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > What I'm wondering is how does the decorators validate and
> > error_handler really work?
>
> Do not ask how sausage is made! Actually, if you _really_ want to know
> how it all works, you'll have to read the source. There's more code
> involved than I can reasonably cover in an email. You'll want to look
> at controllers.py, errorhandling.py and widgets/forms.py.
I tried that method before asking the list. :)
> >Then
> > the error_handler decorator I think makes a HTTPRedirect back to add()
> > if validation fails.
>
> I'm pretty sure that there isn't a HTTPRedirect involved, the add()
> method is called by the error handling code and tg_errors is injected
> into the parameters list.
Yes, I noticed now. It seems wrong that the URL changes to /save but
the page is still showing the /add page.
> > But how does it manage to display the error
> > messages in the form?
>
> tg_errors is a dictionary of formencode.Invalid instances. The form
> widget checks this error dict while building the form and generates
> the message by str()'ing the invalid instance.
I'm probably wrong, but I think you are wrong. If I modify the
original examples add() method to the following:
@expose(template=".templates.add")
def add(self):
return dict(form=comment_form)
I.e, I remove the tg_errors parameter. It still works so tg_errors
seem to be unused by the widgets. FormEncodes error messages must be
passed to the widget using some other mechanism.
> > How does the form know that it should display
> > the values that you wrote there previously when you are redirected
> > back?
>
> The values are still in the CherryPy environmental variables, the
> widgets pull their data from there if they aren't passed in data.
TurboGears stuffs it in request.input_values and request.validation_errors?
> > I would like to implement code similar to the example above, but
> > without using a form widget. And preferably without using the validate
> > and error_handler decorators. Maybe someone can show me an example of
> > that?
>
> The pieces really are designed to work together. You can use them
> separately, but building this system has consumed most of the
> development effort in TurboGears thus far.
>
> I'm curious what you can't accomplish by re-templating the current system.
A few reasons. I want multiple methods that share a save() method:
...
def add_stuff_one_way(self):
return dict(...)
def add_stuff_another_way(self):
return dict(...)
def save(self, ....):
save called from either add_stuff_one_way() or add_stuff_another_way()
In a setup like this, the @error_handler decorator doesn't work
because it only takes one argument.
The other reason is that I don't want to use TurboGears widgets, and
@validate and @error_handler seem to be tightly coupled to the widget
system.
--
mvh Björn
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
