[Zope3-dev] Re: Brainstorming page architecture, pagelets, portlets, etc.

[Jean-Marc Orliaguet]

Tonico Strasser wrote:

> Jean-Marc Orliaguet wrote:
>
>> Tonico Strasser wrote:
>>
>>> Jean-Marc Orliaguet wrote:
>>>
>>>> Tonico Strasser wrote:
>>>>
>>>>> Jean-Marc Orliaguet wrote:
>>>>>
>>>>>> - for the styling, have a pluggable interface to let the layout 
>>>>>> renderer write CSS class names and let portlets, pagelet register 
>>>>>> their own CSS styles (that should be done through a renderCSS() 
>>>>>> method, not through a flat CSS document)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This reminds of a CSS library for Python I've seen some time ago. 
>>>>> I wonder how such a CSS renderer will deal with CSS hacks[1].
>>>>>
>>>>> [1] <http://cthedot.de/cssutils/>
>>>>> [2] <http://css-discuss.incutio.com/?page=CssHack
>>>>>
>>>>> Tonico
>>>>>
>>>>
>>>>
>>>> Hi!
>>>>
>>>> Personally I strictly use no hacks, since most of them are meant to 
>>>> make it possible to use the exact same HTML code in many situations 
>>>> and let the browser handle the negociation/browser detection logic 
>>>> (NS4, IE, text-based browser, hidden boxes, PDA, etc...).
>>>
>>>
>>>
>>>
>>> But I have to deal with CSS hacks every day. Browsers are not 
>>> perfect yet. Here ist an example were I *have to* use some hacks to 
>>> fix browser bugs: <http://www.webproducer.at/flexible-layout/>
>>>
>>> I agree completly with you that avoiding hacks is the best practice, 
>>> but sometimes you can't.
>>>
>>> Tonico
>>
>>
>>
>>
>> Hi! layout rendering in CSS is a tricky issue. It works fine for 
>> simple layouts (3 columns), but if you have a portal with dynamic 
>> content and more advanced layouts ('pagelets' for instance) - then 
>> tables are the safest if not the only choice. Nothing prevents you 
>> from using a tableless renderers though. I am doing advanced layouts 
>> that CSS cannot cope with.
>
>
> Using tables or not comes down to personal opinion or needs.
>
>> But again you can move the selection of a layout renderer to Zope 
>> because trying to solve everything on the browser side is a fight 
>> lost in advance.
>
>
> I don't know how to imagine a layout renderer.
>
>> If you look at the softwares used by on-line newspapers they bet on 
>> the safest choice, i.e. tables.
>
>
> Wired.com, aol.com, mozilla.org, ... are table-less ;)
>
>> It is a matter of being pragmatic and not being too much focused on 
>> being semantically correct all the time.
>
>
> We (our company) need to satisfy accessibility requirements. Semantic 
> coding is part of this job.
>
>> Anyway the idea of having several layout renderers somehow puts and 
>> end to the debate since it makes it possible to choose between 
>> different options.
>
>
> Sounds interesting.
>
> Tonico



basically a layout renderer converts a tree structure in Zope into a 
markup language (XML, HTML). There is an obvious similarity between 
containment in Zope and a rendered page layout. Moving an object (a box, 
a portlet) inside a canvas comes down to moving the same object in 
Zope.  Then you can choose just any markup tag to represent the 
containers of that structure (tables, divs, span ...) as long as the 
structure is preserved during the transformation. uPortal does it in XML 
and page fragments are simply portions of XML code that can be attached 
to nodes in the tree structure. But in Zope you don't need xml to 
achieve the same results. 

Cheers /JM