Exploring Zope

Avi Bryant avi at beta4.com
Tue Oct 28 06:08:20 UTC 2003


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




More information about the Squeak-dev mailing list