cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject [cforms] getWidget removal affecting 2.1.5 release?
Date Mon, 10 May 2004 19:44:10 GMT
hey there,

last friday (before codefreeze) I checked in the new lookupWidget and 
the getWidget to getChild rename...

the first makes every widget a natural starting point for widget-tree 
navigation using a path-like expression (even including construct like ../)

the latter was based on some recent discussion that indicated the higher 
semantical value of getChild over getWidget, and accorded better with 
the getParent counterpart...

this last change however has quite some impact on existing 
installations: current cforms users will need to run through their code 
to search/replace getWidget to getChild (or lookupChild in fact)

out of convenience to our users we might do slightly more though
- clear documentation on the woody2cforms page

and then apply some more gentle phasing out approach of deprecation by
- re-introduce the getwidget, but make it deprecated
in which case we should decide if the implementation should

[ ] just work
[ ] log a warning and keep on working
[ ] fail with some RTE

or we let everybody just live with the consequences of working with 
unstable blocks (in which case the wiki update should suffice)
(of course: if we don't do provide this transition kind of stuff for 
2.1.5 we shouldn't do it at all, so it's now during code freeze or just 
forgetting about it)

reactions welcomed,

PS: by the way: on a related issue I'm now convinced we have everything 
in place now to just ditch the ContainerWidget interface, but this is 
more of a hidden change that can easily happen after 2.1.5 (and together 
with all the other stuff that still needs to happen)
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message