myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Winer <awi...@gmail.com>
Subject Re: svn commit: r345590 - /myfaces/api/trunk/src/java/javax/faces/component/_ComponentUtils.java
Date Tue, 22 Nov 2005 02:29:16 GMT
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 <skitching@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 <skitching@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
> >>
> >>
>
>

Mime
View raw message