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

[Paul Everitt]

(First, I changed the subject line to something that is hopefully ok.)

Jim Fulton wrote:
> Tonico Strasser wrote:

[big snip]

>> Individual pages don't have to invoke the main template directly, the 
>> can call a script that returns a macro with slot definitions. An 
>> indivudal page is only interested in filling slots.
>>
>> What are the problems with that?
> 
> 
> Why should they call anything?
> 
> I'd like people to be able to create pages without worrying about the
> site layout at all.

I agree with Jim.

>> What are the alternatives?
> 
> 
> I don't know.  I'm open to suggestions.  At this point, I'm
> really interested in writing down the problem so that, when we argue about
> solutions, we at least have a chance to argue about solutions to the
> same problems. I'd rather get agreement on the problems before
> getting to far down the road of brainstorming solutions.  Of
> course, brainstorming problems without solutions is like trying to
> decide what kind of yacht I want to buy. There is some feedback
> between problems and their solutions.

This past weekend I went through an exercise of writing down my thoughts 
on pipelines, specifically the part of the problem that this discusison 
focuses on.  I even did some narrated recordings to demonstrate some ideas.

I found a flaw (discussed below) half-way through and had to start over, 
so I'm not finished.  Also, the ideas aren't restricted to this o-wrap 
discussion, so I should probably isolate that part.

I guess the wiki is the right place to write down some theories?

>>   * An additional abstraction layer for better separation of
>>     presentation-structure and presentation-layout?
> 
> 
> Maybe

For the problem statement, this is also my conclusion.

My thinking is that, on an app server or CMS project, there's someone in 
charge of "corporate identity".  They run the existing website's 
templating.  They are smart, but very busy, and would prefer to jump 
into the project for a brief time then jump out.  This means they would 
prefer not to learn any template system nor be involved in ongoing 
development/maintenance.  Let's call them the Web Designer.

ZPT was built to address this role, but the advent of pluggable 
presentation systems like CMF and Zope 3 introduced into templates lots 
of stuff that (IMO) made templates too heavy for casual involvement by 
the web designer.

I'll list, but not explain unless needed, justification: deep and 
undocumented slot/macro hierarchies, default main templates which have 
almost no value when opened directly from disk, non-valid templates 
because the first line has a metal block to insert DTD, trivial changes 
cause 30-line obscure tracebacks for the web designer.

Right now the machinery for the corporate identity and the machinery for 
the integrators&developers all happens in the same processing step, 
using the same technology, and the same physical file.  I now feel that 
this is overloading.  I think that we need something similar to the 
theme-window manager-toolkit layering of desktop environments, where the 
corporate identity person is given a simple, limited, reliable facility 
like theming.

As shorthand, let's call this...uhhh, theming. :^)  Let's say the theme 
is the last step on the way out the door, after the navtree has been 
generated, breadcrumbs created, search results gathered, etc.

A theme starts its life as a wireframe on a whiteboard, in the meeting 
where the (busy) web designer pops in the door and explains the 
corporate identity as boxes on a white board.  It's the Site 
Integrator's job to agree on a contract (the wireframe) and reliably 
fill those boxes.

The theme should be applied whether or not the creator of the 
PanGalacticMessageBoard package remembered to sprinkle anything in or 
not.  Thus, no o-wrap in a messagesearch.pt file.

In small projects, all these roles might be conflated to one person, and 
they might just grab the out-of-the-box theme-window manager-toolkit 
setup and slightly tinker it.  This workflow resembles my experience in 
consulting, though I realize there's a bunch of variance in experiences.

>>   * A new pure UI language?
>>   * XSLT?
> 
> 
> I'm intrigued by:
> 
> - In Cocoon, there is a mechanism for configuring how the parts of
>   a page get assembled that allows the implementation of the parts,
>   including the main part, to be totally independent of the assembly.
>   I'm not saying we should do this the cocoon way, but I think we should
>   try to think of something like this.

This is what I wrote up over the weekend. :^)  The flaw, though, was 
that it shifted the balance of power so far in the direction of 
developers.  The presentation result starts with the content model, 
which gradually gets transformed into flaming logos.  This is sort of a 
push model of processing.

I got intrigued by reversing the process.  Start with how you want the 
page to look.  Pull in the wireframe boxes that need to be rendered. 
Each box is filled by the result of a pipeline that is produced by 
developers and customized by the integrator if needed, for instance to 
hide private workflow states in the tree.

(I'm still conflicted on this part.  Should search.html be designed 
based on the responsibilities it has, or on the boxes it needs to fill?)

For the [o-wrap, corporate identity, theme part], life becomes pretty 
simple.  The Web Designer and Site Integrator agree on a wireframe.  The 
Web Designer hands over a blob of HTML/CSS/JS for the look and feel. 
Each wireframe box gets DOM identifiers (div id="logo").

A second document, the content merge document, gives a static model for 
the data to fill the boxes.  You press a button in your XML editor, and 
a 30 line XSLT does the merge and produces a result page.

That's all there is to theming.  Very reliable, can be developed outside 
Zope, should be pretty fast performance, mature off-the-shelf technology 
with good error messages, and most importantly, no surprises.  You can 
verify if the *dynamic* content merge document that Zope later provides 
is valid or not, and you'll know who to blame and who violated the 
"contract".  Replacing the static boxes with dynamic boxes is decoupled 
into different, validate-able steps.

The workflow would then shift to how this content merge document gets 
specified, assembled, etc.

> - Portlets are objects that are designed to be part of something else.
>   They get stuck into something bigger.  This makes a portlet writers'
>   job easier that page writters' job.
> 
> I suspect this is all related.  I could be wrong.

I have the concern also that I'm all wrong. :^)  There's a tension 
between a highly customizable and pluggable system on large projects 
with several actors, versus a single-pass, easy to grok approach with 
one layer of technology.  Also, there's a tendency to expand scope, such 
as knobs to cache stage results which helps performance but adds another 
thing to be aware of.

Most fundamentally, I can't decide between an outside-in approach to 
presentation (start w/ wireframe, pull in dynamic content) or an 
inside-out (start with the content model, process into presentation).

Also, I am focusing on some design goals about improving productivity 
that others might disagree with.  I want to take the extra time with a 
comprehensive writeup so folks can have *informed* disagreement. :^)

--Paul