On 2/16/12 5:09 AM, Kito Mann wrote:
>
>
> On Wed, Feb 15, 2012 at 11:53 PM, Blake Sullivan
> <blake.sullivan_at_oracle.com <mailto:blake.sullivan_at_oracle.com>> wrote:
>
> 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.
>
>
> The difference here is that the EL variable is "cc". The component is
> simply referring to one of its own properties, not a backing bean, so
> a developer would expect that to work when making an arbitrary call to
> the component.
Unless this is the composite component implementor's own code, then I
would argue that when getting a the disabled property in this case:
1) How does the caller know that the property is not EL-bound
2) How does the caller know that an EL-bound property is only bound to "cc"
3) How does the caller know that for a "cc" bound property, the property
is bound to a property that is not itself EL-bound
4) If the caller knows all this, they probably know the actual
expression in the first place
-- Blake Sullivan
>
>
> 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.
>
>
> True --- I understand the distinction, but it is difficult to get across.
>
>
>
> -- 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 <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
>> >
>> >
>>
>>
>>
>
>