The GUI/html interface was becoming a bit complex and I could no longer simply do straight up HTML/Javascript for some features that we’d need (ie. getting publication lists etc)… and I wasn’t about to wrap every little server side data structure in json to send it out to the client to parse out. The obvious solution was to implement server-side scripting… yeah yeah Python is already the de-facto server-side scripting since it’s already running the Server process itself, but I didn’t want to bloat the Server code with GUI-specific functionality. Also if I’ve learned anything from my years of web development, it’s that you REALLY don’t want to mix HTML (and inevitably Javascript) inside a scripting language… its just nastiness. It’s much nicer to flip it inside out and use a HTML templating technique with embedded python instead (ie. similar to mod_python’s PSP ). Unfortunately the PSP interpreter is stuck to mod_python (the Apache module) and I wasn’t about to emulate the Apache module API just to include mod_python into my webserver… Althoooough that’d be pretty sweet and it’d give me all those mod_* for free from Apache 😛 Nah!
I could just reimplement my old “Embedded-Perl-in-HTML-via-EntityTags-and-<perl>tags-aka-PHTML” code as Python… it WAS pretty sweet and just 2 functions. But alas, due to lack of time and the fact Perl was ideal for the heavy regular expressions I used in it while Python regex I’d have to figure out all over again… also the fact it was totally not a standard templating language but my own cheap albeit beautiful solution ;).
So with a little more Googling I came across the Cheetah Templating Engine (a Python based Templating engine for text). The template syntax seemed a bit esoteric at first but after reading the documentation, experimenting and realizing they were creating a generic templating language (not just HTML) it started making some sense. On the programmer/integrator side of things the Cheetah API is super simple and clean to use. You simply create an instance (or derive your own class from their class) of Template passing in a filename or string containing the template syntax, then you can set arbitrary properties (which become accessible variables from within the template syntax) to the Template instance. Finally whenever the template gets the __str__ call (ie. in print or str() calls) it returns the generated final output.
Within the MocoServer I integrated it such that if the file extension ends in .tmpl it assumes it’s a Cheetah template file (this is Cheetah’s own idea, I just went with it) and calls the Template instance to generate a string and then we send the string out to the client. Additionally I use a sub-file extension to determine the Content-Type to send to the client (ie. .html.tmpl sends text/html, .js.tmpl sends text/javascript etc). All these tmpl files exist in the same htdocs directory as the rest of the web content.
To be of any actual use the template syntax will need access to data from the Server itself, so I went ahead and bound several Server data structures to the template’s attributes. Namely CGI_Params goes to Template.CGI, clientSocket goes to Template.clientSocket and the server instance itself goes to Template.server (security considerations be damned :P). So now any templated file can essentially look up whatever datastructures I’m using in the server, send random junk out to the client or just look at the pre-parsed CGI parameters. Heck it can even invoke methods within the server (ie. stop() the server from inside, such a bad idea :P)
This should certainly make GUI design a bit easier when things need to be tightly integrated with the Server.