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

[Paul Everitt]

Tonico Strasser wrote:
> Amos Latteier wrote:
> 
>> Paul Everitt wrote:
>>
>>> 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.
>>
>>
>>
>> I don't quite understand this and would like to see the scenario.
>>
>> I think that if we're going to separate these concerns:
>> * designing the site layout
>> * creating a view for a piece of content
>> * specifying how content is integrated into the layout
>>
>> It would make sense to figure out how people doing these jobs might 
>> work. So I'm interested in the scenario.
>>
>> My guess is that a site layout should be designed by creating an HTML 
>> page that has some kind of place holders where content should be 
>> integrated into it.
>>
>> I also think that creating views can continue to use ZPT - though 
>> perhaps not with whole page macros. If we don't use whole page macros 
>> we should figure out some way that people creating views can 
>> reasonably preview their work in context.
> 
> 
> I think it is enougth to get the work preview directly from the server 
> (different skin or development server). I don't understand why someone 
> would like to preview a piece of template code from the local 
> filesystem? Or did you mean something different? More important for me, 
> is the ability to validate my HTML.

In thinking about the meeting between the Web Designer and the CMS 
Integrator, "must have functional login to the development server" 
sounds like a cumbersome requirement. :^)

For the moment, let's just dump this aspect into the pile labeled 
"Paul's Weird Ideas" and come back to it later, when I have some 
narrated walkthroughs.  Every time I've explained this to people, 
they've had the same "What's the big deal?" expression.  After I gave a 
demo, the enthusiasm increased a bit.

"Paul's Weird Ideas" include the ability to validate in a friendly tool.

>> It's also nice if we don't break all the great things that ZPT 
>> provides like valid HTML and working with whole HTML pages rather than 
>> invalid snippets.
> 
> 
> It's difficult to create allways valid ZPTs, but it's easy to make them 
> well-formed.
> 
>> Finally I don't yet have any strong ideas about how content is 
>> integrated into a site layout. I'm not sure the XSLT is a great 
>> solution. Personally I dislike XSLT since it's so complex. I'd rather 
>> program in Python than XSLT. So I don't mind if the work is done with 
>> XSLT so long as I don't have to write the XSLT ;-) I'll try to think 
>> about this some more.
> 
> 
> Me too, I learnded a bit of XSLT and was looking for a good XML server, 
> but then I found Zope and ZPTs :)

First, for this theming proposal, XSLT is just one of the possible ways 
to implement the merge.  It isn't something that will every be visible. 
  It's just a black-box way to do the merging, which could be done by 
other technologies.

As a black box theme engine, XSLT has some merits, IMO.  Rather than 
list them, though, I'd like to remove XSLT from the discussion, since 
the theming idea doesn't require it.

Any chance folks could drop by #zope3-dev today and chat about it?  I'm 
around until 4PM GMT+1.

--Paul