cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Date Sun, 31 Aug 2003 11:41:08 GMT
Steven Noels wrote:

> Sylvain Wallez wrote:
>> Example :
>> <wt:widget id="foo">
>>  <wi:styling type="textarea" rows="10"/>
>> </wt:widget>
>> The "type" attribute defines the "style type" and all other 
>> attributes are dependent on this type (and here, copied as is).
>> What do you think ?
> Including the style element directly rather than referring to it with 
> a type attribute leaves for more future expansion room and won't mess 
> up namespaces if you include direct output elements in the 
> <wi:styling/> element, IMHO.

I think I wasn't clear : this applies well to _flat_ styling 
configurations (i.e. a simple list of name/value pairs) as it doesn't 
require an additional nested element (reduced verbosity). But this does 
not prevent the use of nested elements in wi:styling when needed 
(although I haven't encountered this need up to now).

Furthermore, use of attributes ensures uniqueness of styling type, which 
is not guaranteed with nested elements.

E.g. what happens if we write :
<wt:widget id="foo">
    <textarea rows="10"/>
    <password size="20"/>

Will this widget be rendered as a textarea or as a password ? With 
"textarea" or "password" being defined by the unique "type" attribute, 
this problem cannot happen.

Or do we want <wi:styling> to be able to hold different styling 
directives and let the layout stylesheet decide which one is best ? 
Mmmh... too much magic...


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message