[Zope3-dev] Need help planning Zope X3 1.0

[Bjorn Stabell]

Hi,

[ Casey's example ]

Well, the Hapless guy is in deep shit anyways.  Even if he didn't see
the Python code, it'll still be there, under the hood.  He wouldn't be
able to change it.  If he didn't want to change it, he could leave it as
it is, it doesn't matter if it is in the HTML or if it's a separate
method.

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.

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".  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).

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).

Maybe this is not common, but in my experience, designers make great
designs in PSD, and they can transfer it to HTML.  But they aren't very
good at HTML/CSS, their HTML usually sucks.  Our coders, however, are
excellent at it.  HTML/CSS is more akin to coding than it is to design;
you need a programmer's mindset to do it to a high quality, and
CMS-driven sites need a high quality master template.

Bye,
-- 
Bjorn