Photographer: Simone Aguiar / Illustration by Brendan Davis

Lalo Martins- Developer, Open Page Templates / Plone Team.

In the third quarter of '99 a friend called me to start a "website business" (when that was still trendy). I was tasked initially with selecting a development platform; by then pretty much everything was PHP, but I was already a Python advocate and ended up supporting Zope primarily because it was based on Python. Ironically, I have to admit if I was to make this same decision today I would probably go with Twisted.

My first reaction was "eek, no documentation" - by then all we had was the poorly maintained DTML Reference and one other thing I don't remember anymore. But reading source code was no news to me, and that I did, convinced that I had the best tool in my hands. Fortunately, I read the sources of existing products like Squishdot; if I had read stuff like DocumentTemplate, ZPublisher or ZClasses, I would have run away screaming and tried to integrate Python into PHP, or just use mod_python. Then my second reaction was "cool, this thing publishes objects". I had been an OOP person for more than ten years then, so it seemed very alien to me to publish stuff from the filesystem or a relational database; having a big object database where the main UI just happens to be the web sounded to me like the most powerful answer to the web application problem.

What was the original inspiration for your version of Page Templates? How was your work incorporated into Zope Page Templates?

I was occasionally consulting for Hiperlogica, one of the leading Zope solution providers in South America, and their CEO, Luciano Ramalho, called me for a meeting. "We spend too much time working for our customers", he said, "and there are things we would like to get done in Zope itself and don't have time to do ourselves. We would like to have someone working on this." It was an offer for a more permanent job, and I was interested.

I then asked for examples of what ideas he had, and he showed me "xmlc": http://xmlc.enhydra.org/ - the templating language of Enhydra, which was by that time considered a competitor to Zope. The cool thing about xmlc was that its templates were valid XML; you could load them up in Dreamweaver and they would look more or less right, only with fake content, like the stuff you get from professional webdesigners when you don't have the content yet. We discussed the idea of implementing the dynamism in attributes, instead of new, non-standard tags, and I came up with XML namespaces as a way to keep the languages from interfering with each other. He finished with "I would like to have something like this, only done right."

A few days later the company moved to their new office, and I effectively started working for them. However, on the week of the move itself I didn't have anything better to do and I decided to sketch my ideas of what this new "language" would look like. I had recently had my first contact with Extreme Programming, so I did the design in the style we now call "science fiction design" - by writing a template with commands to perform some real-life work, and then using it as a reference to get the system working. You can still, to this day, see this original template, with a few comments, at http://www.zope.org/Members/lalo/HiperDom/sample_template

Well, I may not be the best programmer in the world, but I'm still a programmer... so, when I was satisfied with the spec, I decided to try my hand at a prototype. I started about 9PM and had it ready in the morning; nothing pretty to look at, of course – it was a ZClass that used the now defunct XMLDocument for parsing. But still, it worked, and that was an awesome accomplishment. In my first day in the new office, I downloaded a .zexp file over ssh and showed it to the guys at Hiper. In a moment of humor, I had decided to name it HiperDom, because it did to static DOM more or less what hypertext does with text, but also to brand it as something made at Hiperlogica.

Well, that wasn't my intention, but it was an instant sell. I was allocated to build a "real" implementation in Python, that ran in an acceptable amount of time. My first decision was to store the parsed DOM tree in the ZODB, because parsing XML is inherently slow even with the best parsers. Then two weeks later we had our first public release, which promptly drew a lot of attention, including from Zope Corporation (at that time still Digital Creations), who wanted to develop it with us and make it an official part of Zope.

However, that idea didn't quite work out. After about 3 months of working together, they decided to punt, and shortly after that announced ZPT to us and the world. I wasn't too much offended: TALES, tal:attributes and MeTAL were very powerful solutions to the problems we were having with HiperDom, and the implementation benefited from internal Zope knowledge I didn't have. However, the source code was (and still is) in my opinion absolutely hideous and very hard to maintain; so I thought, "good thing they have someone who gets paid to maintain this mess", and stepped away to deal with my personal life.

This happened in 2002. I was out of Hiperlogica, re-married and doing free-lance work, after some months trying to build a web division in a company in Rio. During that job we built two sites based on Plone, which involved customizing *all* templates we expected the user to ever see, at the very least to translate the messages into Portuguese. Now I had a new contract, and my ability to feed myself and my wife depended on it working; I thought, "what the hell, if I customize all these templates again they will go out of date in a few days, at the rate Plone development happens".

So I had to go i18n. My first attempt consisted in a brute-force approach of filtering all UI messages through ZBabel; obviously, that made the site slower than radioactive decay. So I came across the proposal for ZPT i18n for Zope3 (I was very excited about Zope3 by that time), and I thought, why not implement this? I knew ZPT and TAL were very different internally than HiperDom, but I remembered that in HiperDom it would be very easy to just hook in a new namespace handler. Since ZPT had two namespaces (tal and metal), I figured it had to be possible.

Well.

To summarize: no. (If you ever want to know how hard it was, objectively, ask Florent Guillaume: he ended up doing it.)

Looking at the TAL compiler and interpreter hurt my eyes. Trying to figure it out took my sleep. And my initial attempts to bend it to my will would break seemingly unrelated code. So, I gave up. "If I have a generic XML transform engine to run this thing through, it will be faster to reimplement it from scratch than to understand how it works." By coincidence, I was working on a XML library named PAX (the Pythonic API for XML - a joke with SAX) for a non-zope-related project; adding a transform engine to it took only a few hours.

Then I spent the next few days hunched over the ZPT (TAL/MeTAL) spec, reimplementing it from the ground up, and then modifying a fork of ZPT and TALES to use it. This was eventually released as AltTAL and AltPT, and later renamed to OpenTAL and OpenPT. Now I work for another leading Zope solution provider, "X3ng": http://www.x3ng.com/, and some of our projects depend not only on i18n, but on decent unicode support: OpenPT is a critical component for us, and used in production in many projects.

Right now, if you need full unicode support, go with OpenPT. The underlying libraries, PAX and OpenTAL, are unicode from the ground up.

If you need an application-specific namespace, like SHOW (see my article for an explanation of what this is) or want to implement your own, then OpenPT is the only choice.

If you need to work with non-xmlish templates - for example, dynamic CSS stylesheets or mail messages - OpenPT will probably serve you better: just select "Text" for the "Source Type" property. This property selects the parser.

Finally, if you need to hook in a custom parser – for example, you want dynamic RestructuredText - OpenPT has the hooks you need.

Most interesting new stuff isn't related to Zope. When I changed the package names, I refactored the TALES toolset so that it is usable from Python code without Zope. There are people looking into integrating OpenPT support into Twisted and Webware.

There is also Static, which has an interesting story:

A few weeks ago, I became a member of the GNU webmasters team. The unique requirements of gnu.org tickled my imagination. While it would be a good thing to automate the site, to make it easier to change the layout or the navigation bars, or add new translations, we have a tabu against server-side intelligence because we have dozens of mirrors, and we can't require them to run any particular software. The solution sounds obvious to me: "compile" the pages at edit-time, and keep the results of this compilation in CVS, so that what the servers (main or mirror) see is a static set of HTML and CSS files.

For that purpose, I wrote a subpackage of OpenTAL, aptly named Static. It provides two services: first, it has some Python classes that, when used in a TALES context, allow you to navigate the filesystem more or less the way we Zopistas navigate the ZODB OFS. Second, a set of command-line tools, "tal-make", provides the interface to compile .tal files into static-but-yet-dynamic HTML. While I won't go as far as saying this will be used on gnu.org, it's a very useful set of tools you can use from your Python program; it can also probably serve as the base for a cgi-based PageTemplates lookalike, although this is not in my plans personally (but the Webware guy seems to be planning to use it).

No, but I go to lengths to make sure Plone works equally well on it. For example, code that assumes a linefeed between each element returned by tal:repeat is not acceptable; ZPT inserts a linefeed, but this is not in the spec, so OpenPT doesn't. There aren't many differences, but I test Plone on OpenPT before every release and fix what breaks.

On the other hand, I *am* trying to convince the Plone leaders to ship the installers with PlacelessTranslationService (the translation service we wrote originally for OpenPT, based on the TranslationService from Zope3) instead of Localizer; not because Localizer is bad software or anything, but Placeless is faster and easier to set up. It now works very well with ZPT, and we test all changes against both ZPT and OpenPT to make sure it continues to work.

Can I say Free Software instead?

I help a bit with the GNU and Python websites (still a newbie at Python.org, but starting), and maintain the website of "PicoGUI":http://www.picogui.org which is based on Plone and hosted at Zettai.net.

I also maintain the Python client library for PicoGUI – an interesting GUI environment: you could say roughly it's an alternative to X, aimed at scalability - so it runs equally well on my PDA with 8M RAM, 160x240 pixels monochrome LCD, 16 gray scale, 2" x 3" viewable area, and on my desktop with 256M RAM, 1280x1024, 24bpp, 19" and OpenGL. Besides the website and Python library, I'm the co-designer of a deep restructuring that is going to be PicoGUI 2.0.

I stopped contributing when I started OpenPT; I just had too much on my hands to keep up with. But when it materializes, it will be a much more interesting environment to work with than Zope2, and I'm really looking forward to the day it's mature enough for me to write some simple applications for it. The guys (Paul Everitt and my co-worker Sidnei da Silva) recently convinced me to write simple content classes for Zope3 - things like what we get from CMFDefault: Document, News Item, Link - and possibly hook them to my IDocument proposal (search the Zope3 wiki if you're interested).

If I had to choose one single feature, I'd easily go for the adapter system [Editor: See Steve Alexander's article in Issue 3 of ZopeMag "Introduction to Zope 3" for an explanation of adapters in Zope 3 and a couple of examples], and more specifically, the skins. This is a wonderful tool, done right, object-oriented, and makes me very frustrated for having to deal with the poorly hacked skins tool in CMF in day-to-day work.

It's more interesting to read articles about stuff you don't know. Expositions of tools that are useful yet little-known, such as TextIndexNG and CMFTypes, would catch my eye - and also community-building articles, and profiles, interviews or opinions of people we know - like Paul [Everitt], Sidnei [da Silva], Alan Runyan, Alex Limi, Shane Hathaway, Florent Guillaume, Stephan Ritcher, etc.