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 _at_#$, 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