[Zope3-dev] Re:

[Jim Fulton]

Tonico Strasser wrote:
> Jim Fulton wrote:
> 
>> Tonico Strasser wrote:
>>
>>> Jim Fulton wrote:
>>>
>>>> For me, the scope is broader than that.  Uptimately, the goal is to
>>>> produce pages that end users see.  I see composition at various levels.
>>>> For example, I'm *finally* understanding how poorly our page-macro
>>>> system works.  When a developer defines a page as a view of some
>>>> object, they shouldn't have to say how the page is wrapped with the
>>>> site look and feel. That should be the concern of someone else.
>>>> There should be a mechanism for "composing" these pages with the site
>>>> look at feel.
>>>
>>>
>>>
>>>
>>> Thinking in page templates I would try to solve it this way:
>>
>>
>>
>> I assume by "it" you mean the problem of making individual pages
>> responsible for providing the layout.
> 
> 
> Yes, the individual pages don't need to know about the look and feel.
> 
> [...]
> 
>>>
>>> This way, I can switch to a different layout by using a different 
>>> layout macro (and stylesheet).
>>>
>>> This is a silly example, but I hope you get the idea.
>>
>>
>>
>> Nope, not at all.  Regardless of how you implement the layout,
>> the individual pages have to invoke the main template some how.  I think
>> there are a number of problems with that.  I don't think the solution 
>> lies
>> in more macros.
> 
> 
> 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.

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

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

Maybe

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

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

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