Your points are well taken. Here is the thought process that I followed
however. Velocity is designed to allow for the easy presentation of the
model. To make this happen it has the ability to introspect elements of
the model. This is a source of expressiveness and power in Velocity.
Python objects as represented in Java expose a series of properties. but
in a slightly different way than standard Java beans. If elements of the
model are exposed using Python objects then it makes sense that we would
want a way to expose their properties with a level of connivence similar
to what we have with Java Beans. Extending the introspector/executor model
via a system of plugins so that it can deal with presenting a richer set
of models was my goal here.
Certainly this is possible at the application level, but just as we don't
extract properties into a flat hashmap for substitution for Java beans we
would not want to take special steps in every controller that exposed a
business object to the presentation author. I suppose I could subclass
context totally outside of the Velocity codebase and have it look at
objects that get placed into it so it could wrap them, but it very
important that business logic authors don't need to work about the
mechanics of using one type of object over another and that they don't
have to write boilerplate code.
This is why I thought a plugin system was appropriate.
"Geir Magnusson Jr." <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/13/2001 10:04 PM
Please respond to velocity-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: RFC: Python objects in context
[EMAIL PROTECTED] wrote:
>
> Based on the fact that the Turbine project contains a PythonAssembler I
> guess that people see how valuable Python can be in terms of rapid
> development. Given this what do people think about extending Velocity to
> deal with Python objects being placed into the context directly?
Eh... :)
> I have added support to ASTIdentifier by adding a PythonExecutor that
will
> try to resolve reference from anything that subclasses PyObject. This is
a
> pretty clean fit I think and doesn't require much code. I was about to
> extend ASTMethod to handle the method case, but here is the thing. I
don't
> want to create a solid dependency on Jython in the Velocity codebase.
What
> I would like from people are ideas about how to extend the
AbstractExecutor
> notion to be more like plugable directive and then extend this notion to
> the AST{Identifier, Method, Reference?}
If you can do it in the AST, why not just make a conventionally
introspectable wrapper class for the python stuff...? Then you can drop
that right into the context, and no one is the wiser....
> Then these could walk a runtime defined list of Executors and preform
the
> right handling without needing to link velocity with the handlers
codebase.
> What do people think? Is this just a custom body of work or should we
look
> at adding something like this to the main codebase?
>
> Thanks
> Ben
If you can get away with it at app level, I think you should leave it
there.... My gut is that we don't want to start doing things like this,
especially if you can get away with a simple wrapper.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
