Grant,
I have though about a utility that can be used to ease the pain of
deprecating an TLD tag or attribute. This would help the user/developer
identify where the deprecated tag/attribute is used before it actually
breaks. The utility would:
o Log the deprecation at the warning level.
o The user/developer/... should be able to disable the logging via
configuration.
o The log message should contain the viewId, tag, and attribute
deprecated. The method could be extended to include instruction
at the debug level.
DeprecationUtility.logTag( viewid, tag)
DeprecationUtility.logTag( viewid, tag, attribute)
DeprecationUtility.logTag( viewid, tag, attribute, instructions)
This may be better suited for Shale, but either way it is needed.
We also need a deprecation policy, i.e. use the above utility at least
one release before the tag/attribute is removed.
Paul Spencer
Grant Smith wrote:
Hi,
as part of http://issues.apache.org/jira/browse/MYFACES-654 , I'm about to
remove the attributes in MyFaces that are not present in the RI. My concern
is breaking user's applications that may already depend on these
attributes... for example commandLink's onclick.
In choosing the lesser of two evils, should we rather just leave in the
attributes that users may already (mistakenly) depend on ?
