On 3/5/12 3:16 PM, Edward Burns wrote:
>>>>>> On Fri, 17 Feb 2012 11:55:09 -0800, Blake Sullivan<blake.sullivan_at_oracle.com> said:
> B> On 2/17/12 6:08 AM, Kito Mann wrote:
>
> KM> So, I suppose the question is really whether or not we should support
> KM> the ability to use findComponent() and evaluate the properties outside
> KM> of a tree traversal.
>
> B> We have never been able to support this in the general case, which is
> B> why invokeOnComponent() was invented. We should improve the
> B> documentation and should maybe throw an IllegalStateException when
> B> attempting to evaluate EL attributes on a non-current component during
> B> the development project stage.
>
> Ok, I've made the following change to the documentation to
> UIComponent.findComponent():
>
> Make the second paragraph of the javadoc for that method be:
>
> This method is not intended to be used with components that reside
> inside of an iterating component. To take action on a component inside
> of an iteration, or to find a component given a simple clientId, see
> invokeOnComponent.
It's actually more basic than that--you can't perform any operation on a
component returned by findComponent() that depends directly or
indirectly on the component being in the correct traversal context. In
practice, this means that attempting to retrieve an EL-bound attribute
value is not safe. Iteration is only the most obvious of these
problems, and the one that exists in the spec components.
>
> Now, to comply with your recommendation to throw an
> IllegalStateException, let's look at section "5.6.2 ELResolver for
> Facelets and Programmatic Access". In there, you see a diagram showing
> our ELResolver chain. Blake, would the following comply with your
> recommendation?
>
> Modify the table in section 5.6.2.1 so that for all ELResolver methods,
> if ProjectStage is development, and base is a UIComponent, throw an
> IllegalStateException if base is not equal to the component returned
> from UIComponent.getCurrentComponent()?
Yes. And this should also ensure that implementation code that needs to
mess with the current component, is doing so correctly.
Of course, once the programmers start hitting the
IllegalArgumentExceptions, they will try to use visitTree() or
invokeOnComponent(). At that point, they could start hitting reentrancy
problems with those apis.
-- Blake Sullivan
>
> B> To summarize:
>
> B> For attribute retrieval, findComponent has three issues:
> B> 1) It has no way of establishing context
> B> 2) No way of executing code in a context even if 1) was fixed
> B> 3) Not exactly fast
>
> B> visitTree has the following issues:
> B> 1) clientIds are a pain to deal with for application developers
> B> 2) problems with reentrancy (fixable with context management)
> B> 3) Can be slow, though faster in esssentially all cases than
> B> invokeOnComponent, and can be faster than findComponent for bulk operations
>
> B> The issue with clientIds is that portions of the clientId are an
> B> implementation detail of the components and renderkit. The result is
> B> that developers are not supposed to be hardcoding clientIds into their
> B> code. Developers need a different kind of id that specifies context
> B> like a clientId, but is standardized like a findComponent search
> B> expression. Let's call this a contextId.
>
> B> Given a contextId, we would like to be able to do the following:
> B> 1) Efficiently convert the contextId into an object capable of
> B> establishing and tearing down the context for the component relatively
> B> efficiently. This would require new component apis.
> B> 2) Add a function like findComponentInContext that may return a proxy
> B> for the UIComponent executing in the context object from 1)
> B> 3) Since setting up and tearing down context on every attribute
> B> retrieval is inefficient--framework managed context so that the current
> B> context may be torn down lazily.
>
> Ahh, the tantalizingly succinct paragraph that seems like it addresses
> all my problems at first read, but at second read is shown to raise many
> more questions than it answers! I need some help in defining those "new
> component APIs" that Blake easily mentions in passing.
>
> I've filed 1080-ComponentContextId.
>
> B> As I said, these problems have always existed, it is just that most
> B> developers don't typically notice that their components are executing EL
> B> in the wrong context until the same EL variables start returning
> B> different results based on the context.
>
> B> Calling UIComponent.pushComponentToEL() from application is a seriously
> B> bad idea. It may be your only choice in this case, but you really want
> B> the framework to manage the context for you.
>
>>>>>> On Fri, 17 Feb 2012 13:32:54 -0800, Blake Sullivan<blake.sullivan_at_oracle.com> said:
> B> I don't really agree. We have a usability problem, in that the current
> B> behavior is unexpected. Even if the application developers do realize
> B> they have problems, they run into:
> B> a) The mismatch between what visitTree wants (clientIds) and what they
> B> have (search expressions)
> B> b) Reentrancy problems with visitTree and invokeOnComponent.
>
> B> I believe that my suggested fix is the correct one, the issues are:
>
> B> 1) It is hard
> B> 2) This would almost certainly require yet another round of required
> B> code changes for components that modify the EL Context, just like we did
> B> when we introduced invokeOnComponent() and visitTree().
>
>>>>>> On Mon, 20 Feb 2012 08:16:38 -0800, Edward Burns<edward.burns_at_oracle.com> said:
> EB> And 3) I don't feel the suggested fix has been articulated clearly
> EB> enough for the group or myself to understand and evaluate.
>
> EB> Can someone please step up and do that?
>
> I still need some help in understanding what is being requested
> regarding this discussion thread.
>
> Blake, can you please followup to this email with a sketch of what
> you're looking for?
>
> Thanks,
>
> Ed
>