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

[Jim Fulton]

Paul Everitt wrote:
> 
> (First, I changed the subject line to something that is hopefully ok.)

I think this subject line is a big improvement over the previous
one in this thread. ;)


...

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

Sure. At this point, I'd like to use it as a brainstorming whiteboard.
Lots of things may go away when it becomes a proposal. (I assume you are
refering to http://dev.zope.org/Zope3/PageArchitecture.)

>>>   * An additional abstraction layer for better separation of
>>>     presentation-structure and presentation-layout?
>>
>>
>>
>> Maybe
> 
> 
> For the problem statement, this is also my conclusion.

I don't understand this statement.

> 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 mostly agree with this. I do think in many cases, ZPT's
get too complicated through lack of discipline on the part of
programmers.  In restrospect, I wish we hadn't icluded Python
expressions in ZPT.

...

> 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. 

Me too, finaly. (I remember Amos complaining about this years ago, but I
didn't get it.)

..

> 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.

Yup. For me, this boils down to separation of concerns.

...

>> - 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.

The flaw in what? Your writup? Or Cocoon's page assembly.

I'll note that, for me, the pipiline model isn't what's important
here. What's important is that there is a way to say that a page
is assembled from a bunch of parts that can be designed independently.

(While I heartily support providning support for xslt pipelines,
  I still don't think they're for everyone.  I don't want a
  page-composition model to depend on them any more than I want it
  to depend on ZPT.)

> 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.

This, I think, is the Cocoon model. There are rules (pipelines) that
select an outer page, The outer page then invokes (pulls) other pipelines
to construct the parts.

> (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?)

I don't follow this.

> 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. 

Are the data XHTML? Or some other XML dialect?  IOW, are the presentaton
for the individual pieces already done?

 > You press a button in your XML editor, and
> a 30 line XSLT does the merge and produces a result page.

I don't follow why an editor is involved.  Oh, is this basically
a test that's done with dummy data?

> 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.

IOW, you've separated the development of the theme from the development
of the parts that it assembles.

...
> 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. :^)

Sounds good.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org