[Zope3-dev] Need help planning Zope X3 1.0

[Jeffrey P Shell]

On Feb 9, 2004, at 9:20 PM, Bjorn Stabell wrote:
> 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).

ZPT is not code to me.  It's templating.  It's HTML.  I treat it and 
think of it as such.  And it's an absolute f***ing joy.  I love it.  
I'm happy there's no if/else.  It fits the HTML and XML mindset (much 
better than XSLT), and gives me something that I can see in GoLive.  I 
have customers who can then edit their templates and modify the 
visuals.  I'm still the one responsible for working in the TAL 
statements, but the HTML guys I've worked with (of many different 
intelligences, tools, and backgrounds) have NOT minded it at all.

They hated DTML, because it would cause us to take a visual idea of 
theirs and rip it out into small modular chunks that could not be 
edited in a visual fashion.  And seemingly small changes would take up 
way too much time.

I love ZPT.

I'm hoping that Zope 3 does NOT cripple it for these customers, as I've 
outlined above.  I know ZPT will be full featured (I hope) in TTW 
development mode, but I want to ensure that my customers, who don't 
even fall under the 'scripter' hat, see their site as a whole and can 
continue to edit pages - including dynamic ones - with full macro 
expansion so that they (and I) can see the impact of changes for sites 
that have a small collection of dynamic pages among a lot of static 
ones.  I'll still be the one responsible for providing the public API 
for the site to use and putting the TAL/METAL markup in the target 
pages.  But it's not something that should require views and all that 
to be set up.

That's great for larger scale web applications, and something I've been 
wanting for a while - but I've been increasingly worried that I have a 
lot of customers who I won't be able to transition to Zope 3 easily 
because their sites don't necessarily fall totally in the area of the 
Scriptor (they'll do very little scripting, if any, themselves, and the 
heavy code is placed deeper in the system) nor are they really a web 
application with new Content objects, views, menus, all that stuff.  
I'll be the scripter for them, and a lot of my concerns revolve around 
the perception scripting for the smart-set in this situation is going 
to be difficult because we've stripped the scripter of any real power 
or semi-advanced tools in order to coddle someone we're afraid of 
scaring off.

> 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've had a huge benefit from ZPT.  Primarily because I can have other 
people make it look good, and it's a lot easier for me to keep it 
looking good because the general HTML structure is so well preserved 
when templating rules are added in.  This is aided by tools such as 
GoLive (which has an excellent WebDAV client) which lets me see the 
repercussions of my edits on sites with complex designs; while at the 
same time I can use BBEdit or VIM for sites and pages I make myself.  
Do some templates get really complex so that hand coding is needed to 
make most edits?  Yes.  But I can still see the effect of style sheets, 
table column spans, etc, in a way that makes sense to my HTML side.

Huge benefit.

And it's encouraged me to write better code that builds the data 
structures used in those pages, whereas in DTML (or some other 
language) I may have tried to build those data structures inside the 
template for expediency's sake.  Those data structure builders, playing 
the role of 'code-behind' (to use ASP.NET terms) then have the benefit 
of being cachable (caching the results of the built data structure 
while keeping the page dynamic and responsive to other events), 
reusable, refactorable, etc.

That's a huge benefit to me, and it helps keep the majority of my 
templates much simpler than their DTML counterparts.  Yes - you could 
code this way in DTML (and old Bobo/DTML code promoted this concept), 
but DTML in Zope 2 didn't promote it well, I felt - partially due to 
being hampered by lack of anything like Python Scripts until Zope 2.3, 
and then still held back by confusing namespace rules (which are kept 
very clear in TALES expressions).

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

Some people would say the same about Postscript, and that by hand you 
can generate much better postscript than you can with a tool like 
Illustrator.

It didn't take too much work for me to eke good HTML out of GoLive.  
For the changes that my designers can't make themselves, I can still 
apply major changes in a fraction of the time it used to take with 
DTML.

I just may have lucked out with the people I get to work with.  But 
they don't know TAL.  However, they know enough to sidestep around it 
or keep an eye out for it using split code/source views.