On Fri, Aug 19, 2011 at 3:31 PM, Leonardo Uribe <lu4242_at_gmail.com> wrote:
> Hi
>
> I have been thinking about this and it seems the missing part has to
> be with UIComponent.findComponent(String expr).
>
Hmm.. Isn't the problem really that the ValueExpression implementations have
no reference to the component for which they were created? If the expression
knew which component it was created for, it could use that component to find
the composite component parent (among other things).
What if the spec said that setValueExpression() must use a
"ComponentMethodExpression" instance that held a reference to the component
for which the expression was created?
> I think it is possible to prevent this problem, doing some
> implementation specific tweaks, but from the user point of view, only
> an alternative like a visitTree receiving a findComponent expression
> is reasonable. It could be good to find some use cases where this
> improvement is useful, to support its addition to the spec.
>
I ran into this when a client had implemented multi-field validation inside
of a PostValidateEvent listener. The code uses findComponent() to query the
properties of different input controls, and when I switched them over to
composite components, this broke:
HtmlImputText input = (HtmlImputText)facesContext.findComponent(clientId);
if (input.isDisabled())
{
....
}
(Nevermind the fact that using these types of casts isn't always the best
idea.)
Now, it so happens that clientId now refers to a composite component child,
whereas before it referred to stand-along HtmlInputText component. This code
now returns false when the #{cc.attrs.disabled} expression returns true,
because cc evaluates to null.
Even if we don't solve this for 2.2, the spec should mandate that
implementations throw an exception or something in this case. This is
something developers simply won't expect (I was certainly surprised).
> regards,
>
> Leonardo Uribe
>
> 2011/8/17 Kito Mann <kito.mann_at_virtua.com>:
> > Hello everyone,
> >
> > I just ran into an issue where #{cc.attrs.property} expressions don't
> work
> > when referenced via properties of child components if they're not
> referenced
> > inside of a tree traversal. More information here:
> > https://issues.apache.org/jira/browse/MYFACES-3283 (happens in both
> MyFaces
> > and Mojarra).
> >
> > Section 5.6.2.1 (Implicit Object ELResolver for Facelets and Programmatic
> > Access) of the spec states the following:
> >
> > cc -> the current composite component relative to
> > the declaring page in which the expression appears.
> >
> > Since "current composite component" usually means the current composite
> > being processed during a tree traversal, "cc" can return null when it's
> > referenced elsewhere (i.e. in an action listener);.
> >
> > I'm thinking that the "cc" implicit variable should return the parent
> > composite component in cases where no "current composite component" is
> > available.
> >
> > Thoughts?
> > ---
> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter:
> > jsfcentral
> > +1 203-404-4848 x3
> >
> > * Listen to the latest headlines in the JSF and Java EE
> > newscast:
> http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> > * Keep up with the aftermath of the Oracle/Sun merger:
> > http://www.mergerspeak.com
> >
> >
>