On 25/04/2006, at 4:36, Roger Rohrbach wrote:
>> Or you can factor the common "do something with good values" part
>> into an unexposed method and split your exposed method in various
>> differently-decorated exposed methods, one for each form...
>
> Nope...I tried this already:
>
> @expose(template='templates.save')
> @validate(form='ThisTypeForm')
> def saveThisTypeOfElement:
> return saveElement('ThisType')
>
> def saveElement(type):
> # do the work, return the dict formerly returned by exposed
> methods
>
> It works when there are no errors, but if there are validation errors,
> the exceptions appear in the log, but are not propagated back to the
> app. It appears that the unexposed method would still need to be
> decorated, which leaves me in the same position as before. Or maybe I
> need to assign the results of the factored-out method to local
> variables in the exposed method? If so, it seems like a little too
> much magic is going on.
You need to stack one more decorator to branch to the method that
should handle errors, normally it'ts the one that displays the form,
so it can display previous values and errors in it.
def your_method(self):
return dict(form=form, ...)
@error_handler(your_method):
@validate(form=form)
@expose()
def save(self, ...):
...
> It feels like @validate, widgets.WidgetsDeclaration and their ilk
> encourage an architectural antipattern, which is that objects (forms,
> widgets) are instantiated at compile (i.e., import) time, instead of
> when the application first needs them. I've managed to avoid this to
> some extent by using callables, but I see no way out in this case,
> save
> to eschew TurboGears idioms.
>
> I'd be interested in hearing what others think about this.
I think I'm doing fine with them :) Widget's, for example, are one
thing you'd like to reuse in many requests, hence better not
instantiate them unnecesarily. Most of it's behavior can be
customized when initializing them (like setting an "action" for a
for, a "search_controller" for an AutoComplete...) and the will
likely remain unchanged throughout your application's life. You can
still further override your some parameters (those listed at the
"template_vars" (.9a4) attribute) on a per request basis (to set the
value of a field, for example)
This has a couple of advantages IMO:
1) The template get's compiled once, without incurring in it cost.
Same goes for building a Schema to validate form widgets.
2) You can tweak some parameters at initialization without having to
create a new subclass of Y just for one small change (maybe change
the default validator?) or maybe set a default value.
On the other hand, the fact that you should no longer modify it's
attributes once instantiated can be painful until you get used to. In
practice, however it isn't much of a problem since you can always
override at display()
my .2€
Alberto
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
