Too Busy For Words - the PaulWay Blog

I've started to use Zope as a web interface for doing CGI stuff. It has a lot going for it - it encourages you to break your page down into little modules that each do something relatively simple, and pull all that together via a HTML (actually HTML plus some extra XML bits) template. It encourages you to separate your presentation and your logic by making it really easy to separate out a little bit of logic (e.g that displays a file system date in a nice format) into a separate script rather than jumping through hoops in your presentation template.

Er, hang on, what did I just say? Move a piece of presentation into a script? Does that make sense? I thought we were trying to get away from having presentation in scripts. What I've come to realise is that this is a mantra that people use without actually either meaning it or making sense. It has become a way of pushing whatever technology the proponent is selling, er, giving away. Zope separates presentation from logic, just like Clearsilver, or Microsoft ASP.NET, or PHP, or...

The fallacy here is that it's possible to completely separate presentation from logic. By building a dynamic web site, you're saying that some parts of the presentation are going to change over time, which requires logic to do this. The logic has to know the semantic meaning of what it's switching on and off, and the presentation has to know that some bits of it are going to be switched. Ergo, interlinking. There's no way to avoid it.

Now, it is possible to separate these enough to mean that the logic doesn't write HTML and the HTML doesn't do complex logic. But OTOH the worst examples of pages that are infernally difficult to understand are PHP and ASP pages where the coder (it's never a graphics designer) says "It's too difficult to do this bit of presentation in HTML, I'll just spit bits of HTML out of my code." The worst bits of it turn up on The Daily WTF, but they are the tip of the iceberg that is resting on the vital organs of maintenance web designers everywhere.

What brought on this rant was a brief session on the #zope IRC channel on freenode.org. I asked a pair of questions about how to do fairly simple things (yes, I'm that new to Zope) and every reply was "I'd put that in a Python script". All I was talking about is 'if a picture with this URL (constructed out of a product code) is present, display it now'. Zope provides excellent path introspection in its templating language: I can do exactly what I want with:

<img tal:condition="exists:path:string:container/covers/${item/item_code}.jpg" tal:attributes="src string:/cgi/covers/${item/item_code}.jpg">

But the couple of people I posed this question to suggested that the correct way to do this was to call a python script that would find out if the file existed and write up the IMG tag for you. One even suggested that the exists:path:string idea was a dirty kludge that was against the spirit of Zope and TAL. Instead, I'm supposed to have a separate piece of code somewhere that is called with an item code (which, to pass it the item code, would require me to do <tal:block tal:replace="python:here/item_code_image(item_code = item.item_code)"> Image Goes Here</tal:block> that then mystically returns the correct HTML (i.e. it knows exactly where it's called and what tag it's in). Yeah, like that's reliable design!

The impression I'm getting is that, once again, people are falling for the old trap that moves all logic, and the presentation it controls, out into scripts. The template ends up as a child's handful of calls to the code, which does all the presentation that the template can't be trusted to do. And we're back where we started: locking the designers and artists out of doing what they're good at (designing websites) and making the programmers do everything. Again! As if it was a good idea in the first place.

Now I can see why the web designer in this team of two (that I'm gradually becoming a third of) doesn't want to learn about Zope or TAL. Because the control of what he's actually displaying is off in Code Hell. He not only doesn't want to learn Python, he doesn't have the time to - and he shouldn't have to.

I'm all for separation of code and logic, but web designers can cope with simple repeat loops and conditions if they're easy to understand. It's not too difficult. The beauty of TAL, as opposed to ASP and PHP and Perl and all the other things that web pages are built in, is that it has a XML namespace that things like Dreamweaver can respect and leave alone. My partner can understand TAL when I point it out to her, even though she's never used a programming language in her life.

I do agree with Zope's principal of encouraging people to make small scripts to do simple things, and then binding them together in the template. We should resist the temptation to say "But it's easier to do that in <scripting language of choice>" (BTW, can you believe that some lunatics have taken Zope, a Python system, and made it recognise Perl scripts? Because two languages are so much easier to learn than one! And it's so simple to cross back and forth between them in the same system! What were they smoking?)

It's not as if the Python scripts in Zope are particularly simple, either. You have to start by binding and then grabbing a bunch of extra objects that link you into the Zope namespace. You can print HTML out, but then you have to return what you printed because it didn't actually get printed when you thought it did. If your session variable uses a list, you have to buggerise around with it because it's sort of but not quite a mutable object. Yes, of course, it makes things so much easier!

Keep up the work, guys.