Maybe I'm misunderstanding this, but how is this different than
accessing any other potentially-EL-bound attribute in JSF? EL-bound
values can only be safely evaluated when the component in question is in
the correct context. This means either:
a) During lifecycle processing
b) During a tree visit callback
c) During an invokeOnComponent callback (which is really just a
degenerate version of b)
I agree that this is has always been a major usability problem with JSF,
but that's how JSF is. The code below with findComponent() has always
been wrong. Programmers should not be calling findComponent() and then
attempting to evaluate potentially EL-bound values.
As a side issue, the differences and uses of clientIds, the id
attribute of a components, and what the JSF findComponent documentation
calls "search expressions" are extremely important, but poorly
understood, as this code shows:
HtmlImputText input = (HtmlImputText)facesContext.findComponent(clientId);
The Mojarra source is similarly confused in some places.
-- Blake Sullivan
On 2/15/12 8:37 PM, Kito Mann wrote:
> Does anyone have any thoughts on this issue?
> ___
>
> 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
> * Sign up for the JSFCentral newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>
>
>
> On Fri, Aug 19, 2011 at 6:11 PM, Kito Mann <kito.mann_at_virtua.com
> <mailto:kito.mann_at_virtua.com>> wrote:
>
>
> On Fri, Aug 19, 2011 at 3:31 PM, Leonardo Uribe <lu4242_at_gmail.com
> <mailto: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
> <mailto: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 <tel:%2B1%20203-404-4848%20x3>
> >
> > * 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
> >
> >
>
>
>