You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Grant Smith <wo...@gmail.com> on 2007/05/18 20:23:59 UTC
Removing attributes not in the RI
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 ?
--
Grant Smith
Re: Removing attributes not in the RI
Posted by Bruno Aranda <br...@gmail.com>.
And in MyFaces 1.2 these issues do not exist anymore,
Cheers,
Bruno
On 18/05/07, Manfred Geiler <ma...@gmail.com> wrote:
> Yes, logging at warn level (with some explanation) sounds appropriate
> for me for all stuff that does not violate the spec but might bring
> difficulties with other implementations (or better: the other
> implementation ;-)
>
> --Manfred
>
>
> On 5/18/07, Paul Spencer <pa...@apache.org> wrote:
> > 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 ?
> > >
> > >
> >
> >
>
>
> --
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces
>
Re: Removing attributes not in the RI
Posted by Manfred Geiler <ma...@gmail.com>.
Yes, logging at warn level (with some explanation) sounds appropriate
for me for all stuff that does not violate the spec but might bring
difficulties with other implementations (or better: the other
implementation ;-)
--Manfred
On 5/18/07, Paul Spencer <pa...@apache.org> wrote:
> 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 ?
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
Re: Removing attributes not in the RI
Posted by Paul Spencer <pa...@apache.org>.
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 ?
>
>