PSP, Cheetah, PTL, ZOPE, etc ...

[Graham Dumpleton]

ChuckEsterbrook at yahoo.com (Chuck Esterbrook) wrote in message news:<112e9d13.0108011014.1fb2241a at posting.google.com>...
> grahamd at dscpl.com.au (Graham Dumpleton) wrote in message news:<dc6f5c99.0108010315.70be0de0 at posting.google.com>...
> > Go to:
> > 
> >   http://webware.sourceforge.net/Papers/Templates/
> > 
>  [snip]
> > What I am wanting to know is what we have learnt from all of this. If
> > one were designing yet another template system, what might be the best way
> > of approaching it? The idea being for it to be simple in appearance and
> > use, yet be powerful enough to harness features within the back end server.
> 
> We *did* design YATL this past spring. It started with some examples
> and discussion on the webware-discuss list. Cheetah emerged as our
> victor for various reasons including [a] we liked the design and [b]
> the author took it to maturity.
> 
> ...
>
> Outside of *SP, the 2 major templating camps that I see are "dollar
> sign/pound" or $#, and *ML.
> 
> In $# you use $ for substitution, often with dotted notation such as
> $employee.manager.salary, and # for directives like #if, #for, and
> #set. The idea is to provide enough power for simple display logic,
> but to keep your application logic outside the templates.
>
> ...
>
> The *ML camp uses XML or XML-like tags for all instructions and
> substitutions. ...

Thanks for the analysis and pointers. Gives me more to think about.
I've included below some more details on the system I am looking
at applying this to though, as I am not sure an approach like Cheetah
gives sufficient power to interact with the back end system. I guess
this derives from the fact that I am not really after just a templating
system for HTML pages. To this end, approaches relying on Python
scripting in some form, such as PSP or PTL may result in a system more
able to harness the features of the back end system.

What it comes down to is that the back end system in question effectively
provides a Java bean like mechanism. The Webware PSP implementation provides
a similar mechanism through its "Can" functions, but here the object
accessed must be implemented in Python and be in the same process (I think).
In the system I have, there is a concept of distinct service objects.
These can be written in either Python or C++ and can be in the same process
or in a remote process connected via an internal messaging system.

These service objects can be accessed internally to the distributed
system through its own internal messaging system, or if a service is
exported appropriately, it can be accessed through a number of different
RPC over HTTP protocols including XML-RPC and SOAP. Examples of service
objects may be database adaptors, authentication services, mail services
etc. The methods accessible through these service objects can return all
the basic Python types, lists, dictionaries etc, plus some other extended
types.

Now from what few examples I have of JSP and Beans in books I have at hand,
they use various *ML type constructs to define what the Bean is and to
access attributes, call methods etc. From what I understand, a lot of this
*ML stuff is perhaps needed because of Java's strong typing and need to
instantiate variables before use. In Python I don't see the need for a lot
of the JSP *ML tags related to Beans.

What I mean here can be seen with the "Can" functions in the Webware PSP
implementation. Here one just uses some mechanism to access the equivalent
of the Bean. This may be the actual object, or could feasibly be a magic
auto method dispatching proxy. In the system I am working with, because the
Bean equivalent may or may not be in the same process or even written in
the same language, it would always be a proxy.

Although with a template system like Cheetah you might be able to map a
function to a particular exported method of a service, as far as I can
see, it would always be the case that such a function must return text
capable of being included into a web page. With PSP, the method of a
service object could return some data structure, which the in place code
could iterate over to produce the actual HTML.

In the architecture I have, I guess I am uncomfortable about having code
related to presentation mixed up in the service objects. I suppose that
some service objects may specifically relate to presentation, but in the
main I would want to preserve the idea of services returning data related
to the model, rather than a view of that model.

Having explained the parallels to a Bean type system, maybe you might now
have more ideas or comments. In the mean time I'll go look more at Zope
for ideas as I wasn't necessarily looking at documentation relating to the
now prefered scheme for doing template pages in that system.

BTW, if you are wondering what this system I keep talking about it, have
a look at the Python manual for OSE on "http://ose.sourceforge.net".