While perhaps there are ways to improve findComponent further, I am failing to see the short coming that he describes. He states:

    It would be much better if there would be a standard way to find a component by name. In fact JSF’s UIComponent has a method called findComponent. Unfortunately, this method stops searching the component tree whenever it encounters a naming container when a search is performed.

This is not true when you use a clientId (relative or absolute). For example here's how you use an absolute path:

    componentA.findComponent(":form:container:componentB");

Now if he doesn't want to know the real name of the component (clientId), and wants to search only by a simple id and return a complete list of all matches, as he states, this is trivial:

    public List<UIComponent> usersFindComponents(UIComponent base, String id) {
       List<UIComponent> list = new ArrayList<UIComponent>();
       Iterator<UIComponent> it = base.getFacetsAndChildren();
       while (it.hasNext()) {
          UIComponent comp = it.next();
          if (id.equals(comp.getId())) {
             list.add(comp);
        }
          list.addAll(usersFindComponent(comp, id));
       }
       return list;
    }

While we can add this if this is desirable (I'm not convinced it is -- walking the tree to find all components is not something I'd recommend), I'm missing the "big problem" that supposedly exists here.

Ken

Dan Allen wrote:

Actually, I forgot to mention that findComponent brings up a point we were discussing about possibility introducing an XPath or jQuery-like syntax for finding components that is less laborious.

And the "view actions" is definitely still an outstanding point, to add to your list.

-Dan

On Fri, Dec 11, 2009 at 1:21 PM, Simon Lessard <Simon_Lessard@dmr.ca> wrote:

Hi,

The only valid points remaining seem to be the no state --> style support, as well as conditional validations and find component support.

For the state styling he even point out at how easy it would be to implement #{component} for conditional styleClass. Of course, #{component} was already public when the article was written but I guess he didn't read that part of the specification. Also, that could be adressed with a skinning engine

For the conditional validation, I kind of agree however, but I have yet to think of a really nice way to standaize that.

Finally, for the findComponent, I think invokeOnComponent adresses this decently well.

Regards,

~ Simon

________________________________

From: jsr-314-open-bounces@jcp.org on behalf of Kito Mann
Sent: Fri 12/11/2009 12:57 PM
To: JSR 314 Open Mailing list
Subject: [jsr-314-open] Another big article

FYI, I just saw a tweet about another (not positive) article: http://bit.ly/50sA4f. I haven't finished reading it yet, but we should definitely review it and provide a good response.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action

Virtua, Inc. | http://www.virtua.com <http://www.virtua.com/> | JSF/Java EE training and consulting
http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces FAQ, news, and info | twitter: jsfcentral

+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17

--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen