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