>>>>> 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.
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()?
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
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/