You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/04/26 09:51:01 UTC

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)

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 }


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)

Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2004-04-26 at 09:51, Sylvain Wallez wrote:
> Bruno Dumon wrote:
> 
> >On Sun, 2004-04-25 at 15:10, Sylvain Wallez wrote:

> >>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.

+1

label has been put in the definition only because it was thought to be
convenient.

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


[OT] french names (was Re: [cforms] refactoring questions...)

Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:

> On 26.04.2004 09:51, Sylvain Wallez wrote:
>
>> :-) 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 ;-)
>
>
> Isn't Sylvain *the* French name? I only met two French men IRL, both 
> were named Sylvain - if that's a criteria :) The one were you, the 
> other one worked for Elf Aquitane near by here in Leuna.


Well, actually Sylvain _is_ french although not very frequent (strange 
coincidence that made you meet two of them), but I was more referring to 
my last name, Wallez.

In my family, this name is said to come from Belgium at a time when it 
was dominated by Spain (16th century). Wallez comes from "Wallonie" (the 
french speaking part of Belgium, and the spanish "-ez" suffix found e.g. 
in Martinez, Rodriguez which I've been said to mean "son of". So I'm 
actually a spanish belgian ;-)

"Bruno Dumon" and "Marc Portier" sound so much more typically french 
both by their names and firstnames!

Who knows, maybe I'm actually one of their distant cousins ;-)

Sylvain

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


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)

Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.04.2004 09:51, Sylvain Wallez wrote:

> :-) 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 ;-)

Isn't Sylvain *the* French name? I only met two French men IRL, both 
were named Sylvain - if that's a criteria :) The one were you, the other 
one worked for Elf Aquitane near by here in Leuna.

> 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.

big +1

I often had the case were I copied stuff from the list view (= repeater) 
into the detail view (single elements) and had to rename the elements.

>>> 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.

+1

Joerg