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
|