In non-iterating cases, there is a 1-1 mapping between a component and
its clientId. If the component knew it wasn't being iterated, it could
cache the clientId and then optimize its behavior depending on whether a
ValueExpression needed to be evaluated or not. If a ValueExpression
needed to be evaluated, the clientId could be used to establish the
context in which the ValueExpression needed to be evaluated. There is
some additional complexity here depending on whether the call was made
when a different component had its context setup (reentrant context
setup) and iteration makes this significantly more complicated.
When iteration is involved, what findComponent is returning is
essentially the template for the component, not the component in a
context. For those kinds of cases, what you want is an
invokeOnComponent-like call that is capable of establish context but is
RenderKit-independent (which is why clientIds fail). We use something
like that for automated tests in ADF Faces, using array notation for
iteration.
-- Blake Sullivan
On 2/16/12 12:50 AM, Werner Keil wrote:
>
> How could the problem, e.g. in the code quoted be fixed or usability
> improved?
> Any suggestions.
>
> Am 16.02.2012 05:37 schrieb "Kito Mann" <kito.mann_at_virtua.com
> <mailto:kito.mann_at_virtua.com>>:
>
> 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 <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
> * 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
> >
> >
>
>
>