Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl

[Bruno Dumon <br...@outerthought.org>]

On Sun, 2003-08-31 at 23:16, Steven Noels wrote:
> Sylvain Wallez wrote:
> 
> > 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">
> >  <wi:styling>
> >    <textarea rows="10"/>
> >    <password size="20"/>
> >  </wi:styling>
> > </wt:widget>
> > 
> > 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.

One hypothetical case where this might be useful is when a selection
list is dynamically assigned to a widget, so that then both a text-style
and a list-style can be used depending on the presence of selection-list
data. Of course this is a very special use-case which could then use a
special style-type.

I like the wi:styling/@type proposal, I would start making some changes
in that regard, unless I would then be interfering with stuff you are
preparing?

> 
> Well, it will be up to the stylesheet to define what will happen. And 
> since we can't control how people will make use of that stylesheet (edit 
> it, or better: import it), I was thinking to just give them an isolated 
> zone where they can add any styling info they want,

that zone exists and is the wi:styling element, not?

>  which most likely 
> will be copied verbatim to the output form.

verbatim? Then the form could as well be a static XML file. The XSLT
will at least need to put the widget's value in there. For selection
lists, it's more complicated.

If you really want to build up custom HTML for each individual widget
yourself, I think it might be better to use a JXGenerator-based
approach.

>  Your suggestion hints at 
> having some definitive list of style widgets, something which I doubt 
> will happen.

Nope, that won't happen, but the current situation isn't any good
either.

>  Or we are in a mutual misunderstanding, of course. ;-)
> 
> > 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...
> 
> Definitely. People should be prepared to do some XSL hacking, but we 
> shouldn't provide them with anything but a very basic stylesheet.

AFAICS, Sylvain's proposal will only cause the stylesheet to become
simpler.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl

[Sylvain Wallez <sy...@anyware-tech.com>]

Bruno Dumon wrote:

>On Sun, 2003-08-31 at 23:16, Steven Noels wrote:
>  
>
>>Sylvain Wallez wrote:
>>
>>    
>>
>>>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">
>>> <wi:styling>
>>>   <textarea rows="10"/>
>>>   <password size="20"/>
>>> </wi:styling>
>>></wt:widget>
>>>
>>>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.
>>>      
>>>
>
>One hypothetical case where this might be useful is when a selection
>list is dynamically assigned to a widget, so that then both a text-style
>and a list-style can be used depending on the presence of selection-list
>data. Of course this is a very special use-case which could then use a
>special style-type.
>
>I like the wi:styling/@type proposal, I would start making some changes
>in that regard, unless I would then be interfering with stuff you are
>preparing?
>

I already have it ready on my HD with some additional bonuses (password, 
dates, etc). I'll check that in.

>>Well, it will be up to the stylesheet to define what will happen. And 
>>since we can't control how people will make use of that stylesheet (edit 
>>it, or better: import it), I was thinking to just give them an isolated 
>>zone where they can add any styling info they want,
>>    
>>
>
>that zone exists and is the wi:styling element, not?
>
>  
>
>> which most likely 
>>will be copied verbatim to the output form.
>>    
>>
>
>verbatim? Then the form could as well be a static XML file. The XSLT
>will at least need to put the widget's value in there. For selection
>lists, it's more complicated.
>
>If you really want to build up custom HTML for each individual widget
>yourself, I think it might be better to use a JXGenerator-based
>approach.
>
>  
>
>> Your suggestion hints at having some definitive list of style widgets, something which I doubt will happen.
>>    
>>
>
>Nope, that won't happen, but the current situation isn't any good either.
>

Even if it's likely that many people will write their own stylesheet, we 
must provide enough features for Woody to run nicely out of the box !

And we also should provide some best practices to write their layouts, 
or even better a kind of loose schema for <wi:styling> syntax allowing 
alternate stylesheets sharing the same syntax.

>> Or we are in a mutual misunderstanding, of course. ;-)
>>    
>>
>>>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...
>>>      
>>>
>>Definitely. People should be prepared to do some XSL hacking, but we 
>>shouldn't provide them with anything but a very basic stylesheet.
>>    
>>
>
>AFAICS, Sylvain's proposal will only cause the stylesheet to become simpler.
>

;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com