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 07:51:01 GMT
Bruno Dumon wrote:

>On Sun, 2004-04-25 at 15:10, Sylvain Wallez wrote:
>  
>
>>Marc Portier wrote:
>>
>><snip/>
>>
>>    
>>
>>>Sorry for the massive commit, however when walking around the code it 
>>>only looked like the proverbial tip of the iceberg.
>>>      
>>>
>>Sorry for the delay, but, as we say here "later is better than never"!
>>    
>>
>
>mieux vaut tard que jamais! (had to cheat for this one, you don't want to see my first
attempt ;-)
>  
>

:-) This translation is the right one. I'm always amazed to see that 
French is a foreign language for you and Marc, whose names sound so much 
more frenchy that many french people's name, including mine ;-)

>>And I would add:
>>
>>10/ Split generateSAXFragment() into startSAXFragment() and 
>>endSAXFragment(), which will make it so much easier on the view side to 
>>handle custom SAX fragments for container widgets and embedding of the 
>><wi:styling>.
>>    
>>
>
>+1
>
>What do you have in mind with the "custom SAX fragments for container widgets"?
>  
>

Well "custom" has to be understood as "widget-specific", i.e. a union 
will output something different than a repeater.

For now, markup production for container widgets has to be handled on 
the view side since the single "generateSAXFragment" cannot take into 
account the nested template included into the widget reference.

This makes me think that we could even use <ft:widget> for repeaters 
instead of <ft:repeater-widget>. The word "repeater" doesn't bring much 
value IMO.

>>Note that I'd like also that <wi:styling> could be written in the definition
also, as defining the styling in the widget definition can be a productivity boost with widget
repositories!
>>    
>>
>
>Should be trivial to store this in the form definition.
>  
>

Yep. But this brings some namespace-related questions: "styling" is 
obviously in the instance namespace ("fi"), but if we introduce some 
"fi:" in the definition, what about "label"? The CForms machinery does 
nothing with it except copying it in the template output, so we may 
consider moving it also to the "fi" namespace.

WDYT?

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