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)
I use Cocoon 2.1.4 Woody at my project at the moment. I will probably upgrade in near future as there are some fixes in cforms that I would like to have (calendar.js, early validation on action widgets). And I use getWidget() at the moment heavily, mostly for custom validations. So, yes, I would like to have a solution.
out of convenience to our users we might do slightly more though - clear documentation on the woody2cforms page
Of course this must be documented, but for me this is not enough as I'm aware of the change with or without the docu :)
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 [X] fail with some RTE
If we do nothing, I will mostly fail with "undefined value" error, won't I? Deprecation is clear. "just work" gives no hint on deprecation, you never know that it is deprecated. Logging is also no solution IMO as I would need to search the logs for usages. So I prefer the RTE on usages. I can click through my application without any need to look anywhere for messages where I might have forgotten one getWidget().
Joerg
