I was looking at the decorators that are becomming available for
turbogears development.
I really like the decorator approach, it seem very similar to
interceptors in the java webwork framwork.
The webwork folks added the concept of an interceptor stack. This
allows interceptors to be grouped together under a tag.
It is simply a grouping of interceptors under a name. There are
several predefined interceptor stacks, and it is very easy to define
your own stack to use in your app.
Here are some example of the predefined stacks that come with webworks,
to create you own stack, just give a name, and give a list of
interceptors (decorators).
The thing that I really like about this approach is that it allows you
to define url "classifications", and to define the list of decorators
that provide the functionality of the classification.
It also would allow you to use multiple configurations in development .
For example, I like to develop an app without authorization. Then
added it in after the site works.
With decorator stacks, I could tag my function with a decorator stack.
I would define several version of my decorator stack, based on my
development mode.
I can turn functionality on and off, without changing my code.
We could put these python decorator stacks in a decorator_stack.py that
is included
in controller classes.
# Very rough example
#python code could be used instead of xml for config
if (mode = development):
my_stack=[
file_upload_decorator,
prepare_decorator, # call prepare function in
object to load db info
logger_decorator, # log calls
timer_decorator, # time calls
expose # standard turbogears expose
]
else:
my_stack=[
authorization_decorator, # added for production, or
advanced testing
file_upload_decorator,
prepare_decorator, # call prepare function in
object to load db info
expose # standard turbogears expose
]
On each function, I just use
@interceptor_stack("myAppStack")
def func(....)
This should be simple to implement, it is just a decorator that call
other decorators.
Would something like this be valueable to other people?
Thanks for the great work on TurboGears, it is really growing into a
great product.
Mike
-------------------------------------------------------------------------------------------
some of the stacks that ship with webworks.
They are in the form:
stack definition
description
defaultStack
<interceptor-stack name="defaultStack">
<interceptor-ref name="servlet-config"/>
<interceptor-ref name="prepare"/>
<interceptor-ref name="static-params"/>
<interceptor-ref name="params"/>
<interceptor-ref name="conversionError"/>
</interceptor-stack>
Defines the basic interceptor stack.
It gives the action any servlet-specific
dependencies it has, calls
prepare() on it if it implements
Preparable, sets configuration
and request parameters on the
action, and finds any type conversion
errors.
validationWorkflowStack
<interceptor-stack name="validationWorkflowStack">
<interceptor-ref name="defaultStack"/>
<interceptor-ref name="validation"/>
<interceptor-ref name="workflow"/>
</interceptor-stack>
Builds on the defaultStack and
adds validation and workflow
interceptors. The interceptor-ref to
defaultStack includes all of the
interceptors from that stack. The
validation interceptor calls the
XWork validation framework, and
the workflow interceptor adds the
validation and error-checking workflow
we looked at earlier.
fileUploadStack
<interceptor-stack name="fileUploadStack">
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="defaultStack"/>
</interceptor-stack>
Prepends the fileUpload interceptor
to the default stack to handle a
multipart file upload. See chapter 4
for details of handling file uploads.
componentStack
<interceptor-stack name="componentStack">
<interceptor-ref name="component"/>
<interceptor-ref name="defaultStack"/>
</interceptor-stack>
Adds the component interceptor,
which invokes the Inversion of Control
container to provide the dependencies
for the action.
