[jsr-314-open] Another big article

[Dan Allen]

On Fri, Dec 11, 2009 at 5:39 PM, Ken Paulsen <Ken.Paulsen at 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.

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.

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

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091211/c3db92be/attachment.html