Dan Allen wrote:

On Fri, Dec 11, 2009 at 5:39 PM, Ken Paulsen <Ken.Paulsen@sun.com> wrote:

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");

This is what I object to (as a usage scenario). This is so unbelievably ugly and fragile it makes my mind bleed. We need to have a more elegant way to express this, and I think XPath (or like I said, jQuery if that is a more popular syntax) is a better approach.

Hi Dan,

Can you give an example of how you're imagining it?

And I don't think we should ever have to make a component developer write code to find a component. That is just horrible. We need to have a clean syntax for finding components that can cover 95% of the cases.

I agree.

What makes the situation worse is that there is huge inconsistency between component libraries in how they implement component location. The standard goes down (I think), RichFaces faces goes up then down, Mojarra (impl) goes down then up then down. It's just crazy. We need a more deterministic and extensible solution.

I believe the JavaDoc for the getComponent API is very clear, so I don't think there should be any inconsistency. It's very verbose and detailed to the exact behavior that is expected. Mojarra goes up to the nearest naming container, then searches downward according to the given relative path... the exception is if the path stats with a ':', in which it then starts at the UIViewRoot. All this is described in the JavaDoc for the API in great detail.

I'm being a little dramatic intentionally just to try to channel some of the frustration that I have observed in developers. They really do freak out over this issue.

I understand. To further confirm what you're saying, I invented yet another way to handle this problem as one of the 1st things I did in JSFTemplating. Essentially, if I wanted 1 component to access another, this is what I did:

<component1 id="foo" otherattrributes="..." ...>
    <ui:event type="afterCreate">
       setPageSessionAttribute(key="fooClientId" value="#{component.clientId}");
    </ui:event>
</component1>
    ...
<component2 ...>
    <ui:event type="whatever">
       someHandler(otherComponent="#{pageSession.fooClientId}");
    </ui:event>
</component2>

Since JSFTemplating handlers declare their input types, "otherComponent" is automatically converted from a clientId String to a the UIComponent if needed. The handler just receives the UIComponent instance. The extra work I had to do was to derive and store the clientId for later reference, which is (finally) easy in JSF2 w/ #{component}. When I implemented this in early 2006, I used my own special EL for this (ugly). :) So... I recognize the problem you are stating.

I'm interested to hear how people would like to solve this.

Thanks,

Ken

-Dan

--
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