[Zope3-dev] Need help planning Zope X3 1.0

Edward Muller edwardam at interlix.com
Tue Feb 10 16:26:46 EST 2004


On Mon, 2004-02-09 at 22:20, Bjorn Stabell wrote:
[snip]

> I do understand and appreciate the concern about separating presentation
> from code, but I think reducing the learning curve is the most important
> factor in achieving market share, and without market share there is no
> long-term future for Zope.  Separating presentation from code is vital
> for big projects and products, and just a pain in the butt for small
> hobby projects and for prototyping; we need to cater to both.

Agreed.

> 
> I was reading The Art of Unix Programming by ERS
> http://www.faqs.org/docs/artu/, especially what he says about the Unix
> philosophy to design and modularity struck me as very true.  It had me
> wishing Zope could be simpler, more modular, with clearer (fewer?)
> layers.  Especially the "transparency" and "discoverability" parts of
> Zope are not very ideal.  I'm hoping Zope 3 will be much better.
> 
> To me, the presentation/code separation is the argument against DTML and
> for ZPT as well.  DTML was simple, or at least had the potential to be
> if it was even more Python-esque and was less "magical". 

At this point I consider DTML to be more "magical".

>  ZPT adds
> another layer of complexity by encoding everything into attributes,
> making the logic of your program incredibly complex to track by making
> it hard to visually distinguish HTML from code, and by introducing a
> whole new "attribute programming concept" that doesn't support common
> programming constructs such as if-then (the test-method is such a
> kludge).

There should be no core logic in ZPTs, it wasn't meant for that. Display
login is another thing. <tal:block condition/> tags are meant for
display login, not doing any heavy logic.

ZPT makes things clean, understandable and simple, unlike DTML which
forces you to switch mindsets, allows you to mix application logic with
presentation logic and just generally make for bad coding habits.

> 
> The benefit of ZPT was supposed to be that you can have HTML programmers
> do HTML programming, whereas coders do coding.  In dynamic sites, the
> main template is often hand-coded anyways; and you often only need one
> of it, so you can have your coder copy-paste (or more often recreate)
> the HTML code that the designer made into the template.  That one
> template often has very complex logic which is further made more complex
> if encoded in ZPT.  ZPT templates are, in my experience, much more
> verbose than DTML templates.  I think we bought a small benefit
> (slightly more HTML editor-friendly templates) for a big price (more
> complex templates).

I don't understand the above at all. HTML coder creates template. If
it's HTML, then there is no logic in it. Period. HTML doesn't have logic
in it.

So lets assume you mean that the HTML guy created the template and
explains some additional logic to the back-end developer. That means
someone with zope experience creates a ZPT template from it. During this
process removes the non-display parts of any logic into python scripts
and/or real products. Future pages use this template using METAL and
there is no need to copy/paste.

ZPT are, in my experience, more verbose than DTML at the cost of
simplicity, understandability and cleanliness.

[snip]
-- 
Edward Muller - http://www.interlix.com - "Open Source Specialists"
Dedicated Zope Hosting - Web Hosting - Open Source Consulting
Network & PC Service & Support - Custom Programming
Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572
Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033




More information about the Zope3-dev mailing list