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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
