[ZPT] interesting anti-templates perspective

[Simon Michael]

Avi Bryant wrote:
> Eric Merritt wrote:
> 
>> Not to mention that zope is much easier to use in a
>> common large dev environment where your development is
>> split between graphics artists, html monkeys, coders
>> and admins.
>>
>> In many shops the devs will get together with the
>> artists and admins to design an application. The
>> graphics artists will usually mock up  most of the
>> application in html, then the junior coders will
>> insert templating script and controller code while the
>> more senior guys code up the business logic.
>> In zope the above is fairly strait forward and pretty
>> simple to do for all concerned. In the current web
>> frameworks available in squeak (and probably smalltalk
>> in general) the above type of development is difficult
>> or impossible.
>>  
>>
> I dunno about "smalltalk in general" - VW, at least, has what's supposed 
> to be a pretty faithful clone of the JSP model, which sounds like what 
> you're looking for.
> 
> Personally, I've spent enough time doing the templating thing to realize 
> that it doesn't work.  Templates offer very little in the way of 
> refactoring and higher level abstractions, they have no clear ownership 
> (roundtripping between designers and developers is often painful), they 
> don't integrate well with the development environment (you usually can't 
> use "senders of" with a template), and they get in the way of modularity 
> - designers want to make the templates as close as possible to a full 
> page, whereas developers (should) want to break things down into tiny 
> reusable pieces.
> 
> A different model I'd like to point to is the one we used on the SBlog 
> project.  I did the bulk of the UI development, and Jim Benson did all 
> of the graphic design, but all we agreed on was which tags would exist 
> with which CSS classes.  You can see how we communicated here:  
> http://minnow.cc.gatech.edu/squeak/3481
> 
> This is mostly a dictionary of meanings for various css classes, which 
> Jim put together as he was doing mockups.  There are also various notes 
> to me based on his trying out early versions of the code, where he saw 
> extra tags that should be added or, very occasionally, changes needed to 
> the bare-bones HTML output (which was  all forms, links, divs, spans, 
> and paragraphs, plus one table for the calendar widget).
> 
> I  just placed the css classes into the html generation code as I wrote 
> it, and when I slapped his css files on at the end, the pages looked 
> great.  He could mess with the css completely independently of the code, 
> without dealing with a lot of the detail you would have to know when 
> working with an HTML template (which comes first in the comment header, 
> the timestamp or the author's name? etc).  He could also work on 
> full-page mockups, whereas I broke the UI down into a very fine-grained 
> set of components.
> 
> CSS can be a a pain in the @#$, but if you're looking for an effective 
> division of labor between code and designer, it's the only way to go.  
> Anyone who has doubts about the level of control this gives the designer 
> should go to http://www.csszengarden.com and be disabused...
> 
> Cheers,
> Avi

(He goes on to say that zope page templates are a much better attempt 
than the rest, but still no worth it).