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!
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.
Last updated: | path: tech / zope | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.
Main index
/ tbfw/
- © 2004-2023
Paul Wayper
Valid HTML5