cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.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 08:43:02 GMT


Sylvain Wallez wrote:
> Marc Portier wrote:
> 
>> Sylvain Wallez wrote:
>>
>>> Marc Portier wrote:
>>>
>>> <snip/>
>>>

<snip  />

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

indeed not, that was my remark on deep nested structures.
what id 'done' was remove getWidget from the widget and keep it only on 
container-widget

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

+1

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

I don't get this, sample?

> - 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 definnition on certain fields


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

if I get it correctly then you favour a start/end split cause it would 
allow you to capture which styling on the template level has passed so 
you can surpress it from the definition? And the end-handling would just 
complete with what was 'inherited' from the definition?

makes sense of course

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

yep.

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

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 :-(

do you think we need one?
I'm working on the building process as we speak (to implement the 
reuse/repo) this is easy to take up with that work

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message