[Zope3-dev] Re: How does the rotterdam skin work?

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>>
>> Hi!
>> the problem is not in the skin itself, but in the model  used to create
>> "skins". Filesystem-based skins that depend on ZPT macros are doomed by
>> definition, unless they are designed to cover most of the site layouts
>> you'll find on the internet (for instance the Plone skin is quite
>> generic). But maintaining such a generic skin (HTML + CSS) is a lot
>> of work.
>
>
> While I wouldn't put it *quite* so harshly, I agree.
>
>> Also there is a problem with the target audience: ZPT programmers are
>> not always good graphic designers and UI/ graphic designers are not
>> always good at ZPT / python.
>
>
> ZPT isn't supposed to be grouped with Python. ZPT was definately designed
> for Web Designers -- people who use tools like Dreamwever.  Except for
> the macro
> issue, ZPT has been pretty (as opposed to completely) sucessful in our
> experience.  One thing I'd definately do differently if I could go back
> in time to when we invented ZPT is I would absolutely not include python
> expressions.  In generally, I would have made them computationally less
> powerful.  Our intent was definately that people would not do complex
> computations in ZPT but people have definately abused the power we've
> provided.
>
> I think the biggest problem with the ZPT macro approach to look and feel
> concerns are not separated.  CPSSkins deals with this in it's own way.
> I'd like to see an approach for people not using CPSSkins. :)  I think
> that
> this will involve some sort of post-publishing phase in the publication
> process.
>
> Jim
>
>

Sure, the separation between content and presentation is very clean in
ZPT (assuming python: expressions did not exist..:-) ). The difference
in the two approaches are more deeply grounded I think:

- the page template model starts from the idea of individual web pages
(easy to understand for a web designer) that expands into a whole site
by creating abstractions such as 'page headers', 'slots', etc.. The
starting point is a web *page* which becomes a generic 'template', and
eventually a site as a collection of published objects that use the same
templates. The process is from the particular to the general, the
'template' make it possible to do the transition.

- with cpsskins, the process goes the other way: from general to
particular. The difficulty lies instead in creating particular pages
that do not follow any given pattern. The logic is close to the
development of an application UI that tries to emulate web sites.
 
/JM