|
Dave Cole
djc at object-craft.com.au
Sat Jun 7 20:23:23 EST 2003
>>>>> "Geert" == Geert Jansen <geert at boskant.nl> writes: >> How is the application namespace made available to the templating? Geert> Funny that you should say namespace, because that is the 3rd Geert> and last central concept in Draco ;-) (the others are templates Geert> and handlers). The variables from the "interface" namespace Geert> are available as global variables to all code in templates. I ask about namespaces as they are central to all of these solutions that separate presentation from implementation. The namespace is the conduit. Geert> Other namespaces include "session", "user", "cookie", "config" Geert> and "args". All of these have a different meaning and putting Geert> variables in them does different things. Namespaces are _the_ Geert> mechanism in Draco to use for persistency. In Albatross there are only two namespaces; local and global. This makes expressions in the template language easier to handle. Both namespaces are managed by the execution context. A new execution context and local namespace is created for every browser request. Session values are loaded into and saved from the local namespace by the toolkit. Session values are a subset of the values in the local namespace. The global namespace for template expressions is set to the globals of the code that executed the template. This allows you to do things like this in a page module (code that handles an application page): import os def page_display(ctx): ctx.run_template('env.html') And then in the env.html template: Path is <al-value expr="os.environ['PATH']"> I have been browsing through the Draco documentation. It looks like Draco and Albatross are trying to solve slightly different problems. Correct me if I am wrong, but Draco is designed to run via mod_python. It also seems more narrowly focused than Albatross. This can be either a good thing or a bad thing depending upon the problem you are trying to solve. If the problem fits within the area that Draco targets, then Draco will solve more application problems than Albatross. Albatross is designed as a set of classes that you can mix and match to allow many different deployment options. Currently Request classes are provided for CGI and mod_python deployment. It should be relatively painless to build Request classes for other deployment platforms (Medusa, SimpleHTTPServer, Twisted). Just this week someone sent us 24 lines of code (including blank lines) that allows FastCGI deployment. Session management is implemented via a different set of mixin classes. This currently allows us to store sessions in a session server or in the local filesystem. In the not too distant future we will probably add a new mixin for keeping sessions in memory for FastCGI deployed applications. This will eliminate all of the pickling overhead. >> No argument here. >> >> I have toyed with the idea of experimenting with different >> templating mechanisms in Albatross. The templating is only part of >> the problem that Albatross is trying to address. Geert> Yes, the same goes for Draco here. I've had some requests to Geert> support TAL (OpenTAL) as the templating language, as this is Geert> becoming a sort of de-facto standard. If I get to it one day I Geert> will. I had a serious look at TAL. I really like the attribute and tag level manipulation. I am convinced that the control flow in TAL is not a good idea. Trouble is, I cannot think of anything better for control flow that is consistent with TAL. - Dave -- http://www.object-craft.com.au
|