cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Ant: [cforms] compact notation for <fi:styling>
Date Fri, 23 Sep 2005 15:06:21 GMT
Carsten Ziegeler wrote:

>Reinhard Poetz wrote:
>>>Hi all,
>>>I'd like to introduce a compact notation on form
>>>template elements for 
>>>stylings that require only attributes (the vast
>>>majority of them).
>>>For example, we currently have to write:
>>> <ft:widget id="text">
>>>   <fi:styling type="textarea" rows="10"
>>> </ft:widget>
>>>The compact notation would allow to write:
>>> <ft:widget id="text" type="textarea" rows="10"
>>>The more verbose form will still be allowed, and
>>>both forms will produce 
>>>the same results, as foreign attributes on
>>>"ft:widget" will lead to 
>>>generating a <fi:styling> with these attributes.
>>>Another thing I'd like to change also is the need
>>>submit-on-change="true", making it implicit on
>>>widgets that have some 
>>>attached change listeners.
>>>That will make form templates less verbose and
>>>closer to the traditional 
>>>html syntax.
>>>Any objections?
>>generally not. While reading your proposal I had the
>>idea of using prefixed attributes to make it very
>>clear that they contain styling information:
>><ft:widget id="text" fi:type="textarea" fi:rows="10"
>>This should also help with validation.
>I agree with Reinhard here, we should use the namespace for the styling
>attributes to clearly indicate that these attributes are for styling.

Ok. You're right that this clearly indicates their purpose, even if it's 
3 more keystrokes per attribute :-)

>Apart from that I'm not against your suggestion, but I don't see a real

Well, saving keystokes and enhancing readability ! So the benefit is to 
make the template writer's life easier.

>Imho it gets more complicated as now two different notations
>are possible and users will worry about when to use what, or if there is
>a difference etc.

I think once this is done we should recommend the attribute notation, 
except where hierarchical styling configuration is needed (AFAIR, only 
htmlarea allows this currently).

>In addition creating an fi:styling element out of
>attributes from a ft:widget element might be too much magic.

Remember that most if not all CForms users never see the expanded 
template. Only people writing styling stylesheets have to care about this.

>What happens if you use both?

The stylesheets always use 'fi:styling/@foo' paths. So as long as both 
the <ft:widget> and <fi:styling> do not hold the same attributes, the 
two stylings are merged.

If however the same attribute appears on both, then the concatenation of 
attributes will be used (because of XPath's node-list to string 
conversion) and then the styling will likely malfunction. But that case 
is a buggy template.

>So, if the majority thinks that it's useful, I'm ok with it - but I remain sceptical.

Aren't you tried of:
- unclosing a ft:widget with no styling,
- type fi:styling
- type styling attributes
- close ft:widget
- and finally indent everything?

This proposal is about turning this to just "type styling attributes" :-)


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message