Return-Path: 
 <dev-return-60052-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 76196 invoked from network); 26 Apr 2004 07:51:19 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 26 Apr 2004 07:51:19 -0000
Received: (qmail 19885 invoked by uid 500); 26 Apr 2004 07:50:48 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 19859 invoked by uid 500); 26 Apr 2004 07:50:48 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 19839 invoked from network); 26 Apr 2004 07:50:47 -0000
Received: from unknown (HELO mail.anyware-tech.com) (217.112.237.100)
  by daedalus.apache.org with SMTP; 26 Apr 2004 07:50:47 -0000
Received: from apache.org (firewall.anyware [10.1.0.254])
	by mail.anyware-tech.com (Postfix) with ESMTP id B8F945EB6E
	for <dev@cocoon.apache.org>; Mon, 26 Apr 2004 09:55:16 +0200 (CEST)
Message-ID: <408CBF65.3040901@apache.org>
Date: Mon, 26 Apr 2004 09:51:01 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.6) Gecko/20040113
X-Accept-Language: fr, en, en-us
MIME-Version: 1.0
To: dev@cocoon.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)
References: <20040420221928.11898.qmail@minotaur.apache.org>
	 <4085A446.5050103@outerthought.org>  <408BB8D1.4020409@apache.org>
 <1082903053.4332.212.camel@yum.ot>
In-Reply-To: <1082903053.4332.212.camel@yum.ot>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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 }