On 2/16/12 2:37 PM, Martin Marinschek wrote:
> Hey guys,
>
> this was a deliberate (=not by me) design decision when moving away
> from Facelets: Facelets had a capability of storing (via variable
> mappers) the path from an EL expression up through the chain. You
> could evaluate a value expression anywhere, and it would deliver you
> the correct value.
I don't think that this could handle the iteration case and I believe
that it assumes that VariableMappers are the only way of affecting the
evaluation context. In addition, I don't believe that this dealt with
re-entrant EL evaluation.
-- Blake Sullivan
>
> I don't know why (maybe because in Facelets you had to know a lot of
> stuff when creating the value expressions, and you needed Facelets to
> create those??), but it was decided to move away from this, and now
> you have to be in a tree traversal to evaluate such expressions.
>
> Of course, this is different, and hence people are running into
> troubles. Maybe we should just move back to the Facelets way of doing
> things?
>
> best regards,
>
> Martin
>
> We could move
>
> On 2/16/12, Blake Sullivan<blake.sullivan_at_oracle.com> wrote:
>> 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
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>