<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Dan Allen wrote:
<blockquote
cite="mid:19758da0912111515k51be0048v3811dca63a75e28@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Fri, Dec 11, 2009 at 5:39 PM, Ken Paulsen
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Ken.Paulsen@sun.com">Ken.Paulsen@sun.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">While perhaps there are ways
to improve findComponent further, I am
failing to see the short coming that he describes. He states:<br>
<br>
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.<br>
<br>
This is not true when you use a clientId (relative or absolute). For
example here's how you use an absolute path:<br>
<br>
componentA.findComponent(":form:container:componentB");<br>
</div>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</blockquote>
Hi Dan,<br>
<br>
Can you give an example of how you're imagining it?<br>
<blockquote
cite="mid:19758da0912111515k51be0048v3811dca63a75e28@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
I agree.<br>
<blockquote
cite="mid:19758da0912111515k51be0048v3811dca63a75e28@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:19758da0912111515k51be0048v3811dca63a75e28@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</blockquote>
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:<br>
<br>
<component1 id="foo" otherattrributes="..." ...><br>
<ui:event type="afterCreate"><br>
setPageSessionAttribute(key="fooClientId"
value="#{component.clientId}");<br>
</ui:event><br>
</component1><br>
...<br>
<component2 ...><br>
<ui:event type="whatever"><br>
someHandler(otherComponent="#{pageSession.fooClientId}");<br>
</ui:event><br>
</component2><br>
<br>
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.<br>
<br>
I'm interested to hear how people would like to solve this.<br>
<br>
Thanks,<br>
<br>
Ken<br>
<br>
<blockquote
cite="mid:19758da0912111515k51be0048v3811dca63a75e28@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
-Dan<br>
</div>
</div>
<br>
-- <br>
Dan Allen<br>
Senior Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br>
<br>
<a moz-do-not-send="true" href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a moz-do-not-send="true" href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a moz-do-not-send="true"
href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>
</blockquote>
</body>
</html>