[Zope3-dev] Applying site-wide look-and-feel (Was Re: )

[Amos Latteier]

Hi,

I'm interested in where this discussion is leading. However, like the 
other participants, I don't yet have a clear proposal. Instead, here are 
some ramblings about page architecture.

I like Jim's idea of pages not needing to specify how they will be
integrated into the site layout. This raises the question of who's job
it is to integrate a page into the site layout. I like Paul's notion of 
a site layout designer person who defines the general layout of pages.

I agree that there are problems with page layout using ZPT. By using 
whole page macros we mix together the jobs of displaying an
object, associating that view with a layout, and defining the layout
(though this last job is done by a different page template). Maybe page
templates should just display objects.

Whole page macros are nice (in comparison with DTML headers and footers) 
because they allow much richer layouts than simply
header/content/footer. However filling macro slots can be problematic on
account of not know what slots are available, and not knowing what
variables will be defined when slots are rendered. It's also difficult
to figure out what's going on when examining an application that uses
whole page macros -- you end up doing a lot of searching around in skins
trying to figure out how the parts fit together.

I like composite pages. They seem to solve the problem of allowing 
coarse-grained customization of pages by non-programmers. I also like 
the way
they formalize the idea that a page consists of a layout with slots and
page elements that fill those slots. Another important detail is that
page elements are displayed using a user-selected view. Maybe all pages
should work along these lines (though all pages certainly don't need to
be customizable by non-programmers.) However I'm wary of adding too much
extra work in order to simply display a web page. It should be very easy
to create a web page.

I looked a Cacoon for a few minutes but I don't really understand it
much except that they use a "pipeline" model. My guess is that the
problems we are looking at here have been well explored by many other
projects. There are probably some cool solutions out there.

Maybe we should spend more time clarifying the use cases. I understand 
the use case of displaying a content object using the site look and 
feel. I don't really
understand all the other use cases on the wiki page, and I'm not even 
sure that
they are related enough to be addressed by a page architecture. For
example, I'm not sure how forms fit into the picture.

-Amos