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,
-marc=
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 http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
