Didn't Sean commit a fix for forceId and findComponent lately? regards,
Martin On 11/22/05, Travis Reeder <[EMAIL PROTECTED]> 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 <[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 > > > >> > > > >> > > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
