You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Simon Kitching <sk...@obsidium.com> on 2005/11/20 21:27:38 UTC
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
prophecy@apache.org wrote:
> Author: prophecy
> Date: Fri Nov 18 14:39:47 2005
> New Revision: 345590
>
> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> Log:
> - Made t:message elements work with Ajax errors
> - fixed UIComponent.findComponent to actually work.
>
> Modified:
> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
>
> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> ==============================================================================
> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> @@ -72,6 +72,7 @@
>
> static UIComponent findComponent(UIComponent findBase, String id)
> {
> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> if (idsAreEqual(id,findBase))
> {
> return findBase;
> @@ -80,15 +81,17 @@
> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> {
> UIComponent childOrFacet = (UIComponent)it.next();
> - if (!(childOrFacet instanceof NamingContainer))
> - {
> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> + // TR - this was not finding all components, removing this if statement worked
> + //if (!(childOrFacet instanceof NamingContainer))
> + //{
> UIComponent find = findComponent(childOrFacet, id);
> if (find != null) return find;
> - }
> - else if (idsAreEqual(id,childOrFacet))
> + //}
> + /*else if (idsAreEqual(id,childOrFacet))
> {
> return childOrFacet;
> - }
> + }*/
> }
>
> return null;
>
>
I suspect this change will have broken UIComponentBase.findComponent,
which is a pretty important method. UIComponent.findComponent is
depending on this method to *not* recurse into NamingContainer
components, as it handles those itself.
In particular, I believe this structure is perfectly valid:
subview id="foo" --> absolute id "foo"
UIInput id="bar" --> absolute id "foo:bar"
subview id="bar" --> absolute id "bar"
UIInput id="bar" --> absolute id "bar:bar"
I'm also puzzled why this change was necessary, as I can't find any code
that calls this _ComponentUtils.findComponent method except for
UIComponentBase.findComponent.
Regards,
Simon
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Travis Reeder <tr...@gmail.com>.
ya, he did, but it was in AjaxPhaseListener, I think it would be
better in a more common reusable place. I'm using his method.
Travis
On 11/21/05, Martin Marinschek <ma...@gmail.com> wrote:
> P.S.:
>
> at least he said he would be working on it...
>
> regards,
>
> Martin
>
> On 11/22/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Didn't Sean commit a fix for forceId and findComponent lately?
> >
> > regards,
> >
> > Martin
> >
> > On 11/22/05, Travis Reeder <tr...@gmail.com> wrote:
> > > Ok, thanks for the heads up guys.
> > >
> > > > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > > > to go down, as "forceId" is MyFaces-specific and likely to remain so.
> > >
> > > I think findComponent with a forced id is not just an ajax problem.
> > > Using the ViewRoot as the NamingContainer for the findComponent is
> > > more of an ajax issue though. In any case, I'll keep this all in the
> > > sandbox for now and we can decide what to do with it later.
> > >
> > > Travis
> > >
> > > On 11/21/05, Adam Winer <aw...@gmail.com> wrote:
> > > > Simon is correct.
> > > >
> > > > Part of the TCK rules are that no public classes (or public/protected
> > > > methods) may appear anywhere in the javax.faces implementation
> > > > that are not defined by the spec.
> > > >
> > > > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > > > to go down, as "forceId" is MyFaces-specific and likely to remain so.
> > > >
> > > > Cheers,
> > > > Adam Winer
> > > >
> > > > On 11/21/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > > > Hi Travis,
> > > > >
> > > > > I expect that the leading underscore in the name is there to explicitly
> > > > > mark that that class is *not* part of the public API of this JSF
> > > > > package. That's a fairly common pattern.
> > > > >
> > > > > I'm pretty sure it would be a violation of the TCK for any non-official
> > > > > classes to appear in the javax.faces tree.
> > > > >
> > > > > And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
> > > > > surely it cannot rely on any non-standard features of the MyFaces
> > > > > implementation of the API...
> > > > >
> > > > > Can you provide an implementation that does what you want as part of the
> > > > > Ajax package in tomahawk? That would seem the cleanest place to put this
> > > > > stuff. It would be even cleaner if the Ajax design didn't try to bypass
> > > > > the JSF namespacing in the first place though. Can't the Ajax components
> > > > > use proper client ids rather than require forceId to be used?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Simon
> > > > >
> > > > >
> > > > > Travis Reeder wrote:
> > > > > > Any reason why _ComponentUtils class is not public? And is there any
> > > > > > problem with making it public so I can add a second findComponent
> > > > > > method that will traverse the entire tree?
> > > > > >
> > > > > > Travis
> > > > > >
> > > > > > On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > > > >> prophecy@apache.org wrote:
> > > > > >>> Author: prophecy
> > > > > >>> Date: Fri Nov 18 14:39:47 2005
> > > > > >>> New Revision: 345590
> > > > > >>>
> > > > > >>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > > > > >>> Log:
> > > > > >>> - Made t:message elements work with Ajax errors
> > > > > >>> - fixed UIComponent.findComponent to actually work.
> > > > > >>>
> > > > > >>> Modified:
> > > > > >>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > > > >>>
> > > > > >>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > > > >>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > > > > >>> ==============================================================================
> > > > > >>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > > > > >>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > > > > >>> @@ -72,6 +72,7 @@
> > > > > >>>
> > > > > >>> static UIComponent findComponent(UIComponent findBase, String id)
> > > > > >>> {
> > > > > >>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > > > > >>> if (idsAreEqual(id,findBase))
> > > > > >>> {
> > > > > >>> return findBase;
> > > > > >>> @@ -80,15 +81,17 @@
> > > > > >>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > > > > >>> {
> > > > > >>> UIComponent childOrFacet = (UIComponent)it.next();
> > > > > >>> - if (!(childOrFacet instanceof NamingContainer))
> > > > > >>> - {
> > > > > >>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > > > > >>> + // TR - this was not finding all components, removing this if statement worked
> > > > > >>> + //if (!(childOrFacet instanceof NamingContainer))
> > > > > >>> + //{
> > > > > >>> UIComponent find = findComponent(childOrFacet, id);
> > > > > >>> if (find != null) return find;
> > > > > >>> - }
> > > > > >>> - else if (idsAreEqual(id,childOrFacet))
> > > > > >>> + //}
> > > > > >>> + /*else if (idsAreEqual(id,childOrFacet))
> > > > > >>> {
> > > > > >>> return childOrFacet;
> > > > > >>> - }
> > > > > >>> + }*/
> > > > > >>> }
> > > > > >>>
> > > > > >>> return null;
> > > > > >>>
> > > > > >>>
> > > > > >> I suspect this change will have broken UIComponentBase.findComponent,
> > > > > >> which is a pretty important method. UIComponent.findComponent is
> > > > > >> depending on this method to *not* recurse into NamingContainer
> > > > > >> components, as it handles those itself.
> > > > > >>
> > > > > >> In particular, I believe this structure is perfectly valid:
> > > > > >>
> > > > > >> subview id="foo" --> absolute id "foo"
> > > > > >> UIInput id="bar" --> absolute id "foo:bar"
> > > > > >> subview id="bar" --> absolute id "bar"
> > > > > >> UIInput id="bar" --> absolute id "bar:bar"
> > > > > >>
> > > > > >> I'm also puzzled why this change was necessary, as I can't find any code
> > > > > >> that calls this _ComponentUtils.findComponent method except for
> > > > > >> UIComponentBase.findComponent.
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >> Simon
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Martin Marinschek <ma...@gmail.com>.
P.S.:
at least he said he would be working on it...
regards,
Martin
On 11/22/05, Martin Marinschek <ma...@gmail.com> wrote:
> Didn't Sean commit a fix for forceId and findComponent lately?
>
> regards,
>
> Martin
>
> On 11/22/05, Travis Reeder <tr...@gmail.com> wrote:
> > Ok, thanks for the heads up guys.
> >
> > > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > > to go down, as "forceId" is MyFaces-specific and likely to remain so.
> >
> > I think findComponent with a forced id is not just an ajax problem.
> > Using the ViewRoot as the NamingContainer for the findComponent is
> > more of an ajax issue though. In any case, I'll keep this all in the
> > sandbox for now and we can decide what to do with it later.
> >
> > Travis
> >
> > On 11/21/05, Adam Winer <aw...@gmail.com> wrote:
> > > Simon is correct.
> > >
> > > Part of the TCK rules are that no public classes (or public/protected
> > > methods) may appear anywhere in the javax.faces implementation
> > > that are not defined by the spec.
> > >
> > > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > > to go down, as "forceId" is MyFaces-specific and likely to remain so.
> > >
> > > Cheers,
> > > Adam Winer
> > >
> > > On 11/21/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > > Hi Travis,
> > > >
> > > > I expect that the leading underscore in the name is there to explicitly
> > > > mark that that class is *not* part of the public API of this JSF
> > > > package. That's a fairly common pattern.
> > > >
> > > > I'm pretty sure it would be a violation of the TCK for any non-official
> > > > classes to appear in the javax.faces tree.
> > > >
> > > > And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
> > > > surely it cannot rely on any non-standard features of the MyFaces
> > > > implementation of the API...
> > > >
> > > > Can you provide an implementation that does what you want as part of the
> > > > Ajax package in tomahawk? That would seem the cleanest place to put this
> > > > stuff. It would be even cleaner if the Ajax design didn't try to bypass
> > > > the JSF namespacing in the first place though. Can't the Ajax components
> > > > use proper client ids rather than require forceId to be used?
> > > >
> > > > Regards,
> > > >
> > > > Simon
> > > >
> > > >
> > > > Travis Reeder wrote:
> > > > > Any reason why _ComponentUtils class is not public? And is there any
> > > > > problem with making it public so I can add a second findComponent
> > > > > method that will traverse the entire tree?
> > > > >
> > > > > Travis
> > > > >
> > > > > On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > > >> prophecy@apache.org wrote:
> > > > >>> Author: prophecy
> > > > >>> Date: Fri Nov 18 14:39:47 2005
> > > > >>> New Revision: 345590
> > > > >>>
> > > > >>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > > > >>> Log:
> > > > >>> - Made t:message elements work with Ajax errors
> > > > >>> - fixed UIComponent.findComponent to actually work.
> > > > >>>
> > > > >>> Modified:
> > > > >>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > > >>>
> > > > >>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > > >>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > > > >>> ==============================================================================
> > > > >>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > > > >>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > > > >>> @@ -72,6 +72,7 @@
> > > > >>>
> > > > >>> static UIComponent findComponent(UIComponent findBase, String id)
> > > > >>> {
> > > > >>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > > > >>> if (idsAreEqual(id,findBase))
> > > > >>> {
> > > > >>> return findBase;
> > > > >>> @@ -80,15 +81,17 @@
> > > > >>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > > > >>> {
> > > > >>> UIComponent childOrFacet = (UIComponent)it.next();
> > > > >>> - if (!(childOrFacet instanceof NamingContainer))
> > > > >>> - {
> > > > >>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > > > >>> + // TR - this was not finding all components, removing this if statement worked
> > > > >>> + //if (!(childOrFacet instanceof NamingContainer))
> > > > >>> + //{
> > > > >>> UIComponent find = findComponent(childOrFacet, id);
> > > > >>> if (find != null) return find;
> > > > >>> - }
> > > > >>> - else if (idsAreEqual(id,childOrFacet))
> > > > >>> + //}
> > > > >>> + /*else if (idsAreEqual(id,childOrFacet))
> > > > >>> {
> > > > >>> return childOrFacet;
> > > > >>> - }
> > > > >>> + }*/
> > > > >>> }
> > > > >>>
> > > > >>> return null;
> > > > >>>
> > > > >>>
> > > > >> I suspect this change will have broken UIComponentBase.findComponent,
> > > > >> which is a pretty important method. UIComponent.findComponent is
> > > > >> depending on this method to *not* recurse into NamingContainer
> > > > >> components, as it handles those itself.
> > > > >>
> > > > >> In particular, I believe this structure is perfectly valid:
> > > > >>
> > > > >> subview id="foo" --> absolute id "foo"
> > > > >> UIInput id="bar" --> absolute id "foo:bar"
> > > > >> subview id="bar" --> absolute id "bar"
> > > > >> UIInput id="bar" --> absolute id "bar:bar"
> > > > >>
> > > > >> I'm also puzzled why this change was necessary, as I can't find any code
> > > > >> that calls this _ComponentUtils.findComponent method except for
> > > > >> UIComponentBase.findComponent.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Simon
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Martin Marinschek <ma...@gmail.com>.
Didn't Sean commit a fix for forceId and findComponent lately?
regards,
Martin
On 11/22/05, Travis Reeder <tr...@gmail.com> wrote:
> Ok, thanks for the heads up guys.
>
> > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > to go down, as "forceId" is MyFaces-specific and likely to remain so.
>
> I think findComponent with a forced id is not just an ajax problem.
> Using the ViewRoot as the NamingContainer for the findComponent is
> more of an ajax issue though. In any case, I'll keep this all in the
> sandbox for now and we can decide what to do with it later.
>
> Travis
>
> On 11/21/05, Adam Winer <aw...@gmail.com> wrote:
> > Simon is correct.
> >
> > Part of the TCK rules are that no public classes (or public/protected
> > methods) may appear anywhere in the javax.faces implementation
> > that are not defined by the spec.
> >
> > Also, IMO, requiring "forceId" for AJAX to function is a poor path
> > to go down, as "forceId" is MyFaces-specific and likely to remain so.
> >
> > Cheers,
> > Adam Winer
> >
> > On 11/21/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > Hi Travis,
> > >
> > > I expect that the leading underscore in the name is there to explicitly
> > > mark that that class is *not* part of the public API of this JSF
> > > package. That's a fairly common pattern.
> > >
> > > I'm pretty sure it would be a violation of the TCK for any non-official
> > > classes to appear in the javax.faces tree.
> > >
> > > And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
> > > surely it cannot rely on any non-standard features of the MyFaces
> > > implementation of the API...
> > >
> > > Can you provide an implementation that does what you want as part of the
> > > Ajax package in tomahawk? That would seem the cleanest place to put this
> > > stuff. It would be even cleaner if the Ajax design didn't try to bypass
> > > the JSF namespacing in the first place though. Can't the Ajax components
> > > use proper client ids rather than require forceId to be used?
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> > > Travis Reeder wrote:
> > > > Any reason why _ComponentUtils class is not public? And is there any
> > > > problem with making it public so I can add a second findComponent
> > > > method that will traverse the entire tree?
> > > >
> > > > Travis
> > > >
> > > > On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > >> prophecy@apache.org wrote:
> > > >>> Author: prophecy
> > > >>> Date: Fri Nov 18 14:39:47 2005
> > > >>> New Revision: 345590
> > > >>>
> > > >>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > > >>> Log:
> > > >>> - Made t:message elements work with Ajax errors
> > > >>> - fixed UIComponent.findComponent to actually work.
> > > >>>
> > > >>> Modified:
> > > >>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > >>>
> > > >>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > > >>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > > >>> ==============================================================================
> > > >>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > > >>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > > >>> @@ -72,6 +72,7 @@
> > > >>>
> > > >>> static UIComponent findComponent(UIComponent findBase, String id)
> > > >>> {
> > > >>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > > >>> if (idsAreEqual(id,findBase))
> > > >>> {
> > > >>> return findBase;
> > > >>> @@ -80,15 +81,17 @@
> > > >>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > > >>> {
> > > >>> UIComponent childOrFacet = (UIComponent)it.next();
> > > >>> - if (!(childOrFacet instanceof NamingContainer))
> > > >>> - {
> > > >>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > > >>> + // TR - this was not finding all components, removing this if statement worked
> > > >>> + //if (!(childOrFacet instanceof NamingContainer))
> > > >>> + //{
> > > >>> UIComponent find = findComponent(childOrFacet, id);
> > > >>> if (find != null) return find;
> > > >>> - }
> > > >>> - else if (idsAreEqual(id,childOrFacet))
> > > >>> + //}
> > > >>> + /*else if (idsAreEqual(id,childOrFacet))
> > > >>> {
> > > >>> return childOrFacet;
> > > >>> - }
> > > >>> + }*/
> > > >>> }
> > > >>>
> > > >>> return null;
> > > >>>
> > > >>>
> > > >> I suspect this change will have broken UIComponentBase.findComponent,
> > > >> which is a pretty important method. UIComponent.findComponent is
> > > >> depending on this method to *not* recurse into NamingContainer
> > > >> components, as it handles those itself.
> > > >>
> > > >> In particular, I believe this structure is perfectly valid:
> > > >>
> > > >> subview id="foo" --> absolute id "foo"
> > > >> UIInput id="bar" --> absolute id "foo:bar"
> > > >> subview id="bar" --> absolute id "bar"
> > > >> UIInput id="bar" --> absolute id "bar:bar"
> > > >>
> > > >> I'm also puzzled why this change was necessary, as I can't find any code
> > > >> that calls this _ComponentUtils.findComponent method except for
> > > >> UIComponentBase.findComponent.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Simon
> > > >>
> > > >>
> > >
> > >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Travis Reeder <tr...@gmail.com>.
Ok, thanks for the heads up guys.
> Also, IMO, requiring "forceId" for AJAX to function is a poor path
> to go down, as "forceId" is MyFaces-specific and likely to remain so.
I think findComponent with a forced id is not just an ajax problem.
Using the ViewRoot as the NamingContainer for the findComponent is
more of an ajax issue though. In any case, I'll keep this all in the
sandbox for now and we can decide what to do with it later.
Travis
On 11/21/05, Adam Winer <aw...@gmail.com> wrote:
> Simon is correct.
>
> Part of the TCK rules are that no public classes (or public/protected
> methods) may appear anywhere in the javax.faces implementation
> that are not defined by the spec.
>
> Also, IMO, requiring "forceId" for AJAX to function is a poor path
> to go down, as "forceId" is MyFaces-specific and likely to remain so.
>
> Cheers,
> Adam Winer
>
> On 11/21/05, Simon Kitching <sk...@obsidium.com> wrote:
> > Hi Travis,
> >
> > I expect that the leading underscore in the name is there to explicitly
> > mark that that class is *not* part of the public API of this JSF
> > package. That's a fairly common pattern.
> >
> > I'm pretty sure it would be a violation of the TCK for any non-official
> > classes to appear in the javax.faces tree.
> >
> > And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
> > surely it cannot rely on any non-standard features of the MyFaces
> > implementation of the API...
> >
> > Can you provide an implementation that does what you want as part of the
> > Ajax package in tomahawk? That would seem the cleanest place to put this
> > stuff. It would be even cleaner if the Ajax design didn't try to bypass
> > the JSF namespacing in the first place though. Can't the Ajax components
> > use proper client ids rather than require forceId to be used?
> >
> > Regards,
> >
> > Simon
> >
> >
> > Travis Reeder wrote:
> > > Any reason why _ComponentUtils class is not public? And is there any
> > > problem with making it public so I can add a second findComponent
> > > method that will traverse the entire tree?
> > >
> > > Travis
> > >
> > > On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> > >> prophecy@apache.org wrote:
> > >>> Author: prophecy
> > >>> Date: Fri Nov 18 14:39:47 2005
> > >>> New Revision: 345590
> > >>>
> > >>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > >>> Log:
> > >>> - Made t:message elements work with Ajax errors
> > >>> - fixed UIComponent.findComponent to actually work.
> > >>>
> > >>> Modified:
> > >>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > >>>
> > >>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > >>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > >>> ==============================================================================
> > >>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > >>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > >>> @@ -72,6 +72,7 @@
> > >>>
> > >>> static UIComponent findComponent(UIComponent findBase, String id)
> > >>> {
> > >>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > >>> if (idsAreEqual(id,findBase))
> > >>> {
> > >>> return findBase;
> > >>> @@ -80,15 +81,17 @@
> > >>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > >>> {
> > >>> UIComponent childOrFacet = (UIComponent)it.next();
> > >>> - if (!(childOrFacet instanceof NamingContainer))
> > >>> - {
> > >>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > >>> + // TR - this was not finding all components, removing this if statement worked
> > >>> + //if (!(childOrFacet instanceof NamingContainer))
> > >>> + //{
> > >>> UIComponent find = findComponent(childOrFacet, id);
> > >>> if (find != null) return find;
> > >>> - }
> > >>> - else if (idsAreEqual(id,childOrFacet))
> > >>> + //}
> > >>> + /*else if (idsAreEqual(id,childOrFacet))
> > >>> {
> > >>> return childOrFacet;
> > >>> - }
> > >>> + }*/
> > >>> }
> > >>>
> > >>> return null;
> > >>>
> > >>>
> > >> I suspect this change will have broken UIComponentBase.findComponent,
> > >> which is a pretty important method. UIComponent.findComponent is
> > >> depending on this method to *not* recurse into NamingContainer
> > >> components, as it handles those itself.
> > >>
> > >> In particular, I believe this structure is perfectly valid:
> > >>
> > >> subview id="foo" --> absolute id "foo"
> > >> UIInput id="bar" --> absolute id "foo:bar"
> > >> subview id="bar" --> absolute id "bar"
> > >> UIInput id="bar" --> absolute id "bar:bar"
> > >>
> > >> I'm also puzzled why this change was necessary, as I can't find any code
> > >> that calls this _ComponentUtils.findComponent method except for
> > >> UIComponentBase.findComponent.
> > >>
> > >> Regards,
> > >>
> > >> Simon
> > >>
> > >>
> >
> >
>
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Adam Winer <aw...@gmail.com>.
Simon is correct.
Part of the TCK rules are that no public classes (or public/protected
methods) may appear anywhere in the javax.faces implementation
that are not defined by the spec.
Also, IMO, requiring "forceId" for AJAX to function is a poor path
to go down, as "forceId" is MyFaces-specific and likely to remain so.
Cheers,
Adam Winer
On 11/21/05, Simon Kitching <sk...@obsidium.com> wrote:
> Hi Travis,
>
> I expect that the leading underscore in the name is there to explicitly
> mark that that class is *not* part of the public API of this JSF
> package. That's a fairly common pattern.
>
> I'm pretty sure it would be a violation of the TCK for any non-official
> classes to appear in the javax.faces tree.
>
> And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
> surely it cannot rely on any non-standard features of the MyFaces
> implementation of the API...
>
> Can you provide an implementation that does what you want as part of the
> Ajax package in tomahawk? That would seem the cleanest place to put this
> stuff. It would be even cleaner if the Ajax design didn't try to bypass
> the JSF namespacing in the first place though. Can't the Ajax components
> use proper client ids rather than require forceId to be used?
>
> Regards,
>
> Simon
>
>
> Travis Reeder wrote:
> > Any reason why _ComponentUtils class is not public? And is there any
> > problem with making it public so I can add a second findComponent
> > method that will traverse the entire tree?
> >
> > Travis
> >
> > On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> >> prophecy@apache.org wrote:
> >>> Author: prophecy
> >>> Date: Fri Nov 18 14:39:47 2005
> >>> New Revision: 345590
> >>>
> >>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> >>> Log:
> >>> - Made t:message elements work with Ajax errors
> >>> - fixed UIComponent.findComponent to actually work.
> >>>
> >>> Modified:
> >>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> >>>
> >>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> >>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> >>> ==============================================================================
> >>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> >>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> >>> @@ -72,6 +72,7 @@
> >>>
> >>> static UIComponent findComponent(UIComponent findBase, String id)
> >>> {
> >>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> >>> if (idsAreEqual(id,findBase))
> >>> {
> >>> return findBase;
> >>> @@ -80,15 +81,17 @@
> >>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> >>> {
> >>> UIComponent childOrFacet = (UIComponent)it.next();
> >>> - if (!(childOrFacet instanceof NamingContainer))
> >>> - {
> >>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> >>> + // TR - this was not finding all components, removing this if statement worked
> >>> + //if (!(childOrFacet instanceof NamingContainer))
> >>> + //{
> >>> UIComponent find = findComponent(childOrFacet, id);
> >>> if (find != null) return find;
> >>> - }
> >>> - else if (idsAreEqual(id,childOrFacet))
> >>> + //}
> >>> + /*else if (idsAreEqual(id,childOrFacet))
> >>> {
> >>> return childOrFacet;
> >>> - }
> >>> + }*/
> >>> }
> >>>
> >>> return null;
> >>>
> >>>
> >> I suspect this change will have broken UIComponentBase.findComponent,
> >> which is a pretty important method. UIComponent.findComponent is
> >> depending on this method to *not* recurse into NamingContainer
> >> components, as it handles those itself.
> >>
> >> In particular, I believe this structure is perfectly valid:
> >>
> >> subview id="foo" --> absolute id "foo"
> >> UIInput id="bar" --> absolute id "foo:bar"
> >> subview id="bar" --> absolute id "bar"
> >> UIInput id="bar" --> absolute id "bar:bar"
> >>
> >> I'm also puzzled why this change was necessary, as I can't find any code
> >> that calls this _ComponentUtils.findComponent method except for
> >> UIComponentBase.findComponent.
> >>
> >> Regards,
> >>
> >> Simon
> >>
> >>
>
>
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Simon Kitching <sk...@obsidium.com>.
Hi Travis,
I expect that the leading underscore in the name is there to explicitly
mark that that class is *not* part of the public API of this JSF
package. That's a fairly common pattern.
I'm pretty sure it would be a violation of the TCK for any non-official
classes to appear in the javax.faces tree.
And anyway, Tomahawk is supposed to run on the Sun RI isn't it? So
surely it cannot rely on any non-standard features of the MyFaces
implementation of the API...
Can you provide an implementation that does what you want as part of the
Ajax package in tomahawk? That would seem the cleanest place to put this
stuff. It would be even cleaner if the Ajax design didn't try to bypass
the JSF namespacing in the first place though. Can't the Ajax components
use proper client ids rather than require forceId to be used?
Regards,
Simon
Travis Reeder wrote:
> Any reason why _ComponentUtils class is not public? And is there any
> problem with making it public so I can add a second findComponent
> method that will traverse the entire tree?
>
> Travis
>
> On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
>> prophecy@apache.org wrote:
>>> Author: prophecy
>>> Date: Fri Nov 18 14:39:47 2005
>>> New Revision: 345590
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
>>> Log:
>>> - Made t:message elements work with Ajax errors
>>> - fixed UIComponent.findComponent to actually work.
>>>
>>> Modified:
>>> myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
>>>
>>> Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
>>> URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
>>> ==============================================================================
>>> --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
>>> +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
>>> @@ -72,6 +72,7 @@
>>>
>>> static UIComponent findComponent(UIComponent findBase, String id)
>>> {
>>> + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
>>> if (idsAreEqual(id,findBase))
>>> {
>>> return findBase;
>>> @@ -80,15 +81,17 @@
>>> for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
>>> {
>>> UIComponent childOrFacet = (UIComponent)it.next();
>>> - if (!(childOrFacet instanceof NamingContainer))
>>> - {
>>> + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
>>> + // TR - this was not finding all components, removing this if statement worked
>>> + //if (!(childOrFacet instanceof NamingContainer))
>>> + //{
>>> UIComponent find = findComponent(childOrFacet, id);
>>> if (find != null) return find;
>>> - }
>>> - else if (idsAreEqual(id,childOrFacet))
>>> + //}
>>> + /*else if (idsAreEqual(id,childOrFacet))
>>> {
>>> return childOrFacet;
>>> - }
>>> + }*/
>>> }
>>>
>>> return null;
>>>
>>>
>> I suspect this change will have broken UIComponentBase.findComponent,
>> which is a pretty important method. UIComponent.findComponent is
>> depending on this method to *not* recurse into NamingContainer
>> components, as it handles those itself.
>>
>> In particular, I believe this structure is perfectly valid:
>>
>> subview id="foo" --> absolute id "foo"
>> UIInput id="bar" --> absolute id "foo:bar"
>> subview id="bar" --> absolute id "bar"
>> UIInput id="bar" --> absolute id "bar:bar"
>>
>> I'm also puzzled why this change was necessary, as I can't find any code
>> that calls this _ComponentUtils.findComponent method except for
>> UIComponentBase.findComponent.
>>
>> Regards,
>>
>> Simon
>>
>>
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Travis Reeder <tr...@gmail.com>.
Any reason why _ComponentUtils class is not public? And is there any
problem with making it public so I can add a second findComponent
method that will traverse the entire tree?
Travis
On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> prophecy@apache.org wrote:
> > Author: prophecy
> > Date: Fri Nov 18 14:39:47 2005
> > New Revision: 345590
> >
> > URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > Log:
> > - Made t:message elements work with Ajax errors
> > - fixed UIComponent.findComponent to actually work.
> >
> > Modified:
> > myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> >
> > Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > ==============================================================================
> > --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > @@ -72,6 +72,7 @@
> >
> > static UIComponent findComponent(UIComponent findBase, String id)
> > {
> > + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > if (idsAreEqual(id,findBase))
> > {
> > return findBase;
> > @@ -80,15 +81,17 @@
> > for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > {
> > UIComponent childOrFacet = (UIComponent)it.next();
> > - if (!(childOrFacet instanceof NamingContainer))
> > - {
> > + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > + // TR - this was not finding all components, removing this if statement worked
> > + //if (!(childOrFacet instanceof NamingContainer))
> > + //{
> > UIComponent find = findComponent(childOrFacet, id);
> > if (find != null) return find;
> > - }
> > - else if (idsAreEqual(id,childOrFacet))
> > + //}
> > + /*else if (idsAreEqual(id,childOrFacet))
> > {
> > return childOrFacet;
> > - }
> > + }*/
> > }
> >
> > return null;
> >
> >
>
> I suspect this change will have broken UIComponentBase.findComponent,
> which is a pretty important method. UIComponent.findComponent is
> depending on this method to *not* recurse into NamingContainer
> components, as it handles those itself.
>
> In particular, I believe this structure is perfectly valid:
>
> subview id="foo" --> absolute id "foo"
> UIInput id="bar" --> absolute id "foo:bar"
> subview id="bar" --> absolute id "bar"
> UIInput id="bar" --> absolute id "bar:bar"
>
> I'm also puzzled why this change was necessary, as I can't find any code
> that calls this _ComponentUtils.findComponent method except for
> UIComponentBase.findComponent.
>
> Regards,
>
> Simon
>
>
Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Posted by Travis Reeder <tr...@gmail.com>.
This was because when you use forceId, it doesn't work. Which is also
very important, I tried to keep this out until a better solution went
in. The reason this didn't work (from what I recall when I first
commented this out), was because it didn't decend into a
NamingContainer. If I'm doing a findComponent on ViewRoot, shouldn't
it find the component anywhere in the tree? Fast forward ... I just
answered my own question looking at the javadocs, says it shouldn't
descend into other NamingContainers. So much for that. I'll put this
back in and try to figure out a better workaround.
Travis
On 11/20/05, Simon Kitching <sk...@obsidium.com> wrote:
> prophecy@apache.org wrote:
> > Author: prophecy
> > Date: Fri Nov 18 14:39:47 2005
> > New Revision: 345590
> >
> > URL: http://svn.apache.org/viewcvs?rev=345590&view=rev
> > Log:
> > - Made t:message elements work with Ajax errors
> > - fixed UIComponent.findComponent to actually work.
> >
> > Modified:
> > myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> >
> > Modified: myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
> > URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java?rev=345590&r1=345589&r2=345590&view=diff
> > ==============================================================================
> > --- myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java (original)
> > +++ myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java Fri Nov 18 14:39:47 2005
> > @@ -72,6 +72,7 @@
> >
> > static UIComponent findComponent(UIComponent findBase, String id)
> > {
> > + //System.out.println("findBase: " + findBase + " - " + findBase.getId());
> > if (idsAreEqual(id,findBase))
> > {
> > return findBase;
> > @@ -80,15 +81,17 @@
> > for (Iterator it = findBase.getFacetsAndChildren(); it.hasNext(); )
> > {
> > UIComponent childOrFacet = (UIComponent)it.next();
> > - if (!(childOrFacet instanceof NamingContainer))
> > - {
> > + //System.out.println("childorfacet: " + childOrFacet + " - " + childOrFacet.getId());
> > + // TR - this was not finding all components, removing this if statement worked
> > + //if (!(childOrFacet instanceof NamingContainer))
> > + //{
> > UIComponent find = findComponent(childOrFacet, id);
> > if (find != null) return find;
> > - }
> > - else if (idsAreEqual(id,childOrFacet))
> > + //}
> > + /*else if (idsAreEqual(id,childOrFacet))
> > {
> > return childOrFacet;
> > - }
> > + }*/
> > }
> >
> > return null;
> >
> >
>
> I suspect this change will have broken UIComponentBase.findComponent,
> which is a pretty important method. UIComponent.findComponent is
> depending on this method to *not* recurse into NamingContainer
> components, as it handles those itself.
>
> In particular, I believe this structure is perfectly valid:
>
> subview id="foo" --> absolute id "foo"
> UIInput id="bar" --> absolute id "foo:bar"
> subview id="bar" --> absolute id "bar"
> UIInput id="bar" --> absolute id "bar:bar"
>
> I'm also puzzled why this change was necessary, as I can't find any code
> that calls this _ComponentUtils.findComponent method except for
> UIComponentBase.findComponent.
>
> Regards,
>
> Simon
>
>