cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Date Mon, 26 Apr 2004 09:09:59 GMT
Marc Portier wrote:

>> The flexibility introduced by decoupling start/endSAXFragment is not 
>> on the widget side, but on the template side: it allows to much more 
>> easily handled nested template instructions. This has several uses:
>> - as of today, SAX events for container widgets must be completely 
>> implemented on the template side. Decoupling start/end allows 
>> container markup to be defined in the widget
>
>
> I don't get this, sample?


Have a look at EffectWidgetReplacingPipe.UnionHandler: production of 
"wi:union" is written in the template generator. Having 
start/endSAXFragment allows to move this to the widget itself.

Of course, this isn't totally equivalent to today's generateSAXFragment, 
since in the case of container widgets it iterates recursively on its 
children. But this behaviour is of use only with the FormGenerator (who 
uses it?).

>> - if we allow "fi:styling" in the definition (which is needed IMO), 
>> we must still retain the possibility to override it in the template. 
>> The associated logic on the template side will be much more easy to 
>> implement.
>
>
> didn't think of this yet,
> in any case we will need some overriding/merging rules for the 
> @defines/@extends thing as well, I guess similar ones should apply for 
> letting template override its definition on certain fields


That's a different problem, as it has to be handled at the definition 
level, by defining the delegation/overriding policy of @extends widgets.

<snip/>

>> Do you mean that it has been decided to move label/help/hint to the 
>> "fi" namespace within the definition? Missed that...
>>
>
> ah, you are right, it wasn't done
> hm, I'm quite sure we decided on this, no?
>
> this is the only thing I can find on this: 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106942146927334&w=2
> I'ld have to agree it doesn't sound like a formal decission though :-(


Not a formal decision, but looks like a general consensus ;-)

Anyway, a formal +1 from me!

Sylvain

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


Mime
View raw message