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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > >> [EMAIL PROTECTED] 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 > > >> > > >> > > > > >
