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

[Paul Everitt]

Jim Fulton wrote:
> 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.)

I'll create a new page, linked from there.  I don't want my rambling to 
be confused for an official part of your discussion, but rather as an 
option.

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

I agree that we need a different abstraction for the o-wrap part of 
presentation.

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

Perhaps.  It's hard to tell which tail wags which dog. :^)  If you open 
up CMF's main_template.pt (which is sort of the o-wrap for CMF), and 
inspect the first screenful of lines, you see 2 things that dominate the 
source and distract from the web designer's job:

1) A metal block at the top, where a DTD or XML declaration should be.

2) 15 lines of tal defines.

Still, I think Amos' reply gave a more elegant explanation than mine, so 
I'll drop the subject. :^)

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

BTW, I think it totally rocks that Amos posted.  Hi Amos!!

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

So far I think we all agree that the o-wrap thing should be a separate 
concern, perhaps more separate than the current ZPT approaches in CMF or 
Zope 3 provide?

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

My writeup.

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

Yes, I agree.  I need to be more careful not to mix things in my posts. 
   I'll put a page in the wiki that doesn't talk about pipelines and 
confines itself to this o-wrap/theme idea.

> 
> (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 don't think pipelines should be limited to XSLT.  Perhaps not even 
XML.  They should permit XSLT, though, for people that might want that 
pattern.

> 
>> 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'll volunteer to writeup some review of this.

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

It's too hard to explain, I'll drop it. :^)

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

The merge takes two input documents.  One is, of course, the theme 
document, as written by the Web Designer.  Probably XHTML, but perhaps HTML.

The merge document contains data to shove into the theme document. 
Thus, it also is an XHTML document.

So yes, the merge document is already done.  It is generated as a result 
of the Site Integrator's involvement in the project.   It is there job 
to take the Zope data and generate markup to fill boxes.

The merge document is the result of several documents and data sources. 
  It's beyond the scope, though, of this o-wrap/theme discussion. 
Appropriately, too, since this means the web designer will never, never 
see any of that machinery.

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

Yes, exactly.  This is done as part of an iterative dialog b/w the web 
designer and the integrator.  They gradually build a dummy merge.xhtml 
that fulfills all the requirements.  As they do this, they can run 
generate a result and look at it until the "contract" is valid.  This 
requires no Zope, since it is just files on disk.

It's the integrators job to go off and make sure Zope produces a valid 
merge document.   Since Zope uses the exact same transform as the XML 
editor, the only real variable is the merge document.  If Zope's 
(dynamically generated) merge document is valid WRT the static one used 
during brainstorming, then the results are predictable.

If not, it is easy to inspect and discover what went wrong.

Stated differently:

1) There is a theme.xhtml document (with all the JS, CSS, and images 
that go with it).  This is owned by the web designer.  The exact same 
artifact is used, unchanged, in Dreamweaver, the XML editor for static 
merging, and Zope for dynamic merging.

2) There is a merge.xhtml document.  During brainstorming, a static file 
is used by an XML editor for rapid prototyping w/out Zope.  Later, this 
is generated by Zope.  Two can be easily compared.

3) There is a merge.xsl document.  This is the transform that takes (1) 
and (2) and produces a result.  This is identical when used in 
brainstorming and in Zope.  However, in Zope you might choose to replace 
it with something faster than XSLT, if there is a better technique for 
merging.

My next step is to write this as a scenario and put it in the wiki, 
along w/ some narrated movies to show it in practice.

--Paul