You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Simon Kitching <sk...@obsidium.com> on 2005/10/31 01:13:07 UTC
Incompatible changes to AddResource class
Hmm..I've just been looking at the recent changes to the AddResource
class in tomahawk's SVN trunk.
It looks to me like the API of this class has changed in an incompatible
manner, thus breaking every custom component that uses the
AddResource.addJavaScriptToHeader method.
In addition, it looks like the class now prefixes URLs with the context
path by default [AddResource.getResourceUri calls
ViewHandler.getResourceURL which prepends the context]
This change will break every user jsp file which specifies a
javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
HtmlAccordionPanel (and others) as formerly users *had* to include the
context path, and now it is *always* prepended to the provided url.
While I do like the new behaviour, and find it more useful than the old
behaviour, I'm sure a little more attention to backwards compatibility
would be appreciated by MyFaces users. And at the very least, I think
backwards-incompatible changes such as this really should be clearly
announced on the mail lists, and noted in the SVN commit message.
Regards,
Simon
Re: Incompatible changes to AddResource class
Posted by Martin Marinschek <ma...@gmail.com>.
Dunno. WIKI, component documentation?
There is an open jira issue now for this - so together with an
explanation in the WIKI, this might be enough.
regards,
Martin
On 10/31/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> Simon is right we should tell the users that this behavior has been
> changed. Any suggestions how/where we should do this?
>
> 2005/10/31, Martin Marinschek <ma...@gmail.com>:
> > Sorry - you are right, I was wrong.
> >
> > Can you help us out and provide a documentation patch for this? Or
> > open a jira-issue?
> >
> > regards,
> >
> > Martin
> >
> > On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > Hi Martin,
> > >
> > > I wish I was mistaken, but I don't think so.
> > >
> > > This page shows the history of the AddResource class:
> > > http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/component/html/util/AddResource.java?rev=329151&view=log
> > >
> > > Select "view" for version 328330, and search for "getResourceURL". You
> > > will find no matches; this version of the class didn't use that method.
> > >
> > > Select "view" for version 328404. The code is completely different,
> > > including the implementation of method
> > > public static void addJavaScriptToHeader(Class componentClass,
> > > String baseDirectory, String resourceFileName, boolean defer,
> > > FacesContext context)
> > > And searching will show that this later class *does* use
> > > "getResourceURL" from the ViewHandler class. This method is defined by
> > > the spec to prepend the context path onto the provided parameter. And
> > > that's exactly what I see when I run my app (which used to work) with
> > > the latest code - the context path getting put on the front.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> > > Martin Marinschek wrote:
> > > > I have looked back into the svn log until the 17.8.2005 - no change in
> > > > this method until this time.
> > > >
> > > > Obviously you must have mistaken something - that also renders your
> > > > other mail about the context not being prepended invalid!
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > >> Hmm..I've just been looking at the recent changes to the AddResource
> > > >> class in tomahawk's SVN trunk.
> > > >>
> > > >> It looks to me like the API of this class has changed in an incompatible
> > > >> manner, thus breaking every custom component that uses the
> > > >> AddResource.addJavaScriptToHeader method.
> > > >>
> > > >> In addition, it looks like the class now prefixes URLs with the context
> > > >> path by default [AddResource.getResourceUri calls
> > > >> ViewHandler.getResourceURL which prepends the context]
> > > >>
> > > >> This change will break every user jsp file which specifies a
> > > >> javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
> > > >> HtmlAccordionPanel (and others) as formerly users *had* to include the
> > > >> context path, and now it is *always* prepended to the provided url.
> > > >>
> > > >> While I do like the new behaviour, and find it more useful than the old
> > > >> behaviour, I'm sure a little more attention to backwards compatibility
> > > >> would be appreciated by MyFaces users. And at the very least, I think
> > > >> backwards-incompatible changes such as this really should be clearly
> > > >> announced on the mail lists, and noted in the SVN commit message.
> > > >>
> > > >>
> > > >> Regards,
> > > >>
> > > >> Simon
> > > >>
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > > Your JSF powerhouse -
> > > > JSF Trainings in English and German
> > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>
>
> --
> Mathias
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Incompatible changes to AddResource class
Posted by Mathias Brökelmann <mb...@googlemail.com>.
Simon is right we should tell the users that this behavior has been
changed. Any suggestions how/where we should do this?
2005/10/31, Martin Marinschek <ma...@gmail.com>:
> Sorry - you are right, I was wrong.
>
> Can you help us out and provide a documentation patch for this? Or
> open a jira-issue?
>
> regards,
>
> Martin
>
> On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> > Hi Martin,
> >
> > I wish I was mistaken, but I don't think so.
> >
> > This page shows the history of the AddResource class:
> > http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/component/html/util/AddResource.java?rev=329151&view=log
> >
> > Select "view" for version 328330, and search for "getResourceURL". You
> > will find no matches; this version of the class didn't use that method.
> >
> > Select "view" for version 328404. The code is completely different,
> > including the implementation of method
> > public static void addJavaScriptToHeader(Class componentClass,
> > String baseDirectory, String resourceFileName, boolean defer,
> > FacesContext context)
> > And searching will show that this later class *does* use
> > "getResourceURL" from the ViewHandler class. This method is defined by
> > the spec to prepend the context path onto the provided parameter. And
> > that's exactly what I see when I run my app (which used to work) with
> > the latest code - the context path getting put on the front.
> >
> > Regards,
> >
> > Simon
> >
> >
> > Martin Marinschek wrote:
> > > I have looked back into the svn log until the 17.8.2005 - no change in
> > > this method until this time.
> > >
> > > Obviously you must have mistaken something - that also renders your
> > > other mail about the context not being prepended invalid!
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> > >> Hmm..I've just been looking at the recent changes to the AddResource
> > >> class in tomahawk's SVN trunk.
> > >>
> > >> It looks to me like the API of this class has changed in an incompatible
> > >> manner, thus breaking every custom component that uses the
> > >> AddResource.addJavaScriptToHeader method.
> > >>
> > >> In addition, it looks like the class now prefixes URLs with the context
> > >> path by default [AddResource.getResourceUri calls
> > >> ViewHandler.getResourceURL which prepends the context]
> > >>
> > >> This change will break every user jsp file which specifies a
> > >> javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
> > >> HtmlAccordionPanel (and others) as formerly users *had* to include the
> > >> context path, and now it is *always* prepended to the provided url.
> > >>
> > >> While I do like the new behaviour, and find it more useful than the old
> > >> behaviour, I'm sure a little more attention to backwards compatibility
> > >> would be appreciated by MyFaces users. And at the very least, I think
> > >> backwards-incompatible changes such as this really should be clearly
> > >> announced on the mail lists, and noted in the SVN commit message.
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Simon
> > >>
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>
--
Mathias
Re: Incompatible changes to AddResource class
Posted by Martin Marinschek <ma...@gmail.com>.
Sorry - you are right, I was wrong.
Can you help us out and provide a documentation patch for this? Or
open a jira-issue?
regards,
Martin
On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> Hi Martin,
>
> I wish I was mistaken, but I don't think so.
>
> This page shows the history of the AddResource class:
> http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/component/html/util/AddResource.java?rev=329151&view=log
>
> Select "view" for version 328330, and search for "getResourceURL". You
> will find no matches; this version of the class didn't use that method.
>
> Select "view" for version 328404. The code is completely different,
> including the implementation of method
> public static void addJavaScriptToHeader(Class componentClass,
> String baseDirectory, String resourceFileName, boolean defer,
> FacesContext context)
> And searching will show that this later class *does* use
> "getResourceURL" from the ViewHandler class. This method is defined by
> the spec to prepend the context path onto the provided parameter. And
> that's exactly what I see when I run my app (which used to work) with
> the latest code - the context path getting put on the front.
>
> Regards,
>
> Simon
>
>
> Martin Marinschek wrote:
> > I have looked back into the svn log until the 17.8.2005 - no change in
> > this method until this time.
> >
> > Obviously you must have mistaken something - that also renders your
> > other mail about the context not being prepended invalid!
> >
> > regards,
> >
> > Martin
> >
> > On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
> >> Hmm..I've just been looking at the recent changes to the AddResource
> >> class in tomahawk's SVN trunk.
> >>
> >> It looks to me like the API of this class has changed in an incompatible
> >> manner, thus breaking every custom component that uses the
> >> AddResource.addJavaScriptToHeader method.
> >>
> >> In addition, it looks like the class now prefixes URLs with the context
> >> path by default [AddResource.getResourceUri calls
> >> ViewHandler.getResourceURL which prepends the context]
> >>
> >> This change will break every user jsp file which specifies a
> >> javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
> >> HtmlAccordionPanel (and others) as formerly users *had* to include the
> >> context path, and now it is *always* prepended to the provided url.
> >>
> >> While I do like the new behaviour, and find it more useful than the old
> >> behaviour, I'm sure a little more attention to backwards compatibility
> >> would be appreciated by MyFaces users. And at the very least, I think
> >> backwards-incompatible changes such as this really should be clearly
> >> announced on the mail lists, and noted in the SVN commit message.
> >>
> >>
> >> Regards,
> >>
> >> Simon
> >>
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Incompatible changes to AddResource class
Posted by Simon Kitching <sk...@obsidium.com>.
Hi Martin,
I wish I was mistaken, but I don't think so.
This page shows the history of the AddResource class:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/component/html/util/AddResource.java?rev=329151&view=log
Select "view" for version 328330, and search for "getResourceURL". You
will find no matches; this version of the class didn't use that method.
Select "view" for version 328404. The code is completely different,
including the implementation of method
public static void addJavaScriptToHeader(Class componentClass,
String baseDirectory, String resourceFileName, boolean defer,
FacesContext context)
And searching will show that this later class *does* use
"getResourceURL" from the ViewHandler class. This method is defined by
the spec to prepend the context path onto the provided parameter. And
that's exactly what I see when I run my app (which used to work) with
the latest code - the context path getting put on the front.
Regards,
Simon
Martin Marinschek wrote:
> I have looked back into the svn log until the 17.8.2005 - no change in
> this method until this time.
>
> Obviously you must have mistaken something - that also renders your
> other mail about the context not being prepended invalid!
>
> regards,
>
> Martin
>
> On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
>> Hmm..I've just been looking at the recent changes to the AddResource
>> class in tomahawk's SVN trunk.
>>
>> It looks to me like the API of this class has changed in an incompatible
>> manner, thus breaking every custom component that uses the
>> AddResource.addJavaScriptToHeader method.
>>
>> In addition, it looks like the class now prefixes URLs with the context
>> path by default [AddResource.getResourceUri calls
>> ViewHandler.getResourceURL which prepends the context]
>>
>> This change will break every user jsp file which specifies a
>> javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
>> HtmlAccordionPanel (and others) as formerly users *had* to include the
>> context path, and now it is *always* prepended to the provided url.
>>
>> While I do like the new behaviour, and find it more useful than the old
>> behaviour, I'm sure a little more attention to backwards compatibility
>> would be appreciated by MyFaces users. And at the very least, I think
>> backwards-incompatible changes such as this really should be clearly
>> announced on the mail lists, and noted in the SVN commit message.
>>
>>
>> Regards,
>>
>> Simon
>>
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>
Re: Incompatible changes to AddResource class
Posted by Martin Marinschek <ma...@gmail.com>.
I have looked back into the svn log until the 17.8.2005 - no change in
this method until this time.
Obviously you must have mistaken something - that also renders your
other mail about the context not being prepended invalid!
regards,
Martin
On 10/31/05, Simon Kitching <sk...@obsidium.com> wrote:
>
> Hmm..I've just been looking at the recent changes to the AddResource
> class in tomahawk's SVN trunk.
>
> It looks to me like the API of this class has changed in an incompatible
> manner, thus breaking every custom component that uses the
> AddResource.addJavaScriptToHeader method.
>
> In addition, it looks like the class now prefixes URLs with the context
> path by default [AddResource.getResourceUri calls
> ViewHandler.getResourceURL which prepends the context]
>
> This change will break every user jsp file which specifies a
> javascriptLocation attribute on tags such as JSCookMenu, HtmlTree,
> HtmlAccordionPanel (and others) as formerly users *had* to include the
> context path, and now it is *always* prepended to the provided url.
>
> While I do like the new behaviour, and find it more useful than the old
> behaviour, I'm sure a little more attention to backwards compatibility
> would be appreciated by MyFaces users. And at the very least, I think
> backwards-incompatible changes such as this really should be clearly
> announced on the mail lists, and noted in the SVN commit message.
>
>
> Regards,
>
> Simon
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German