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> wrote:
>
> 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
>> >
>> >
>>
>
>