Re: [cforms] getWidget removal affecting 2.1.5 release?
Joerg Heinicke wrote: On 10.05.2004 21:44, Marc Portier wrote: - 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(). +1 Vadim
Re: [cforms] getWidget removal affecting 2.1.5 release?
Vadim Gritsenko wrote: Joerg Heinicke wrote: On 10.05.2004 21:44, Marc Portier wrote: - 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(). +1 yep, had the same feeling and did this earlier today. (and thx for fixing my english) regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
[cforms] getWidget removal affecting 2.1.5 release?
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, -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 Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] getWidget removal affecting 2.1.5 release?
On 10.05.2004 21:44, Marc Portier wrote: 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
Re: [cforms] getWidget removal affecting 2.1.5 release?
Marc Portier wrote:
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
[X] fail with some RTE
If we have decided to change the API (and I'm +1 for this one), then
let's do it quick, and fail hard to ease migration of existing
applications. There's nothing worse than something that used to work but
no more does with no particular reason. Sometimes, the dynamic nature of
JavaScript doesn't help...
We'll remove the getWidget() method completely later.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
