Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <408CC2E6.7090609@apache.org>
Date: Mon, 26 Apr 2004 10:05:58 +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
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>
 <408C20D8.5050801@outerthought.org>
In-Reply-To: <408C20D8.5050801@outerthought.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marc Portier wrote:

>
>
> 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"!
>>
>
> yep, thx for chiming in
>
>>> >   - left quite some TODO markers for next sweaps
>>>
>>> Maybe some of you have some suggestions on some of them, feel free 
>>> to step in and comment:
>>>
>>> 1/ should getWidget(id) be removed from Widget? It is already on 
>>> ContainerWidget (which is the true context that makes sense IMHO)
>>
>>
>>
>>
>> +1 from a theoretical POV, but -1 from a practical one! This will 
>> lead to many casts to traverse a widget tree, e.g.
>>    form.getWidget("choice").getWidget("union").getWidget("foo")
>> will become
>>    
>> ((UnionWidget)((ChoiceWidget)form.getWidget("choice")).getWidget("union")).getWidget("foo") 
>>
>
>
> aargh, did this already


Do you mean that you already wrote similar complex code? Were you 
comfortable with this notation? I guess not ;-)

>> Or we may extend getWidget() so that it accepts a path (dotted 
>> notation) instead of a simple name, which would allow e.g.
>>    form.getWidget("choice.union.foo")
>
>
> makes sense, but I haven't seen that much so deep nested structures 
> yet, but surely one we could add to the virtual todo list :-)


Actually, after some further thoughts, getWidget(path) seems the most 
convenient to me, and doesn't break the architectural beauty of having 
getWidget() only on container widgets.

<snip/>

>> 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>.
>
>
> hm, actually since the start/end is always grouped and quite similar 
> to all widgets I've made the spilt slightly different:
>
> generateSAXFragment will do the start/end of the containing element, 
> by asking getXMLElementName() and getXMLElementAttributes from the 
> derived concrete subclass
>
> inserting other stuff in between is done by subclassing 
> generateItemSAXFragment
>
> hope you can live with that to get the same flexibility?
> (the only flexibility you loose imho is the ability to produce not 
> welformed XML by mismatching your end and start events :-))


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

An important point is that startSAXFragment should output all the 
widget's markup except the endElement for the toplevel element, so that 
some filtering can be implemented on the template side (e.g. overriding 
fi:styling as explained above).

>> 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!
>
>
> maybe we could just treat it like the display-data?


+1. wi:styling *is* some display data!

> (we made that move to the wi namespace as well, so it doesn't seem to 
> unlogic, no?)


Do you mean that it has been decided to move label/help/hint to the "fi" 
namespace within the definition? Missed that...

Sylvain

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