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 }
