LU> The first thing to notice is the description here is not what is
LU> happening right now in Mojarra (2.0 and 2.1). The description found
LU> in UIComponent.setParent is more close to the reality (the
LU> conditions related to parent.isInView() ) but the part that says
LU> "... but only if any of the following conditions are true ..." is
LU> not being preserved.
When reading Leonadro's post from 23 Jan 2011 [1], the above paragraph
is the first actionable text I encountered. The desired action seems to
be to fix this bug in mojarra.
Leonardo then goes on to assert that our working assumption, that we *do
not* want to deliver PostAddToViewEvent during renderResponse when
Facelets temporarily removes/re-adds existing components from the tree,
is false for certain cases.
LU> there are valid scenarios in facelets when it is required to throw
LU> PostAddToViewEvent (for example, an ui:include src="#{someEL}"
LU> should propagate that event so the view could be restored).
Leonardo asserts that this case does not work in Mojarra for the
following reason.
LU> Mojarra still uses a Listener attached to PostAddToViewEvent, making
LU> UIComponent.getClientId() "unstable".
Are you talking about inner class AddRemoveListener in class
StateContext?
LU> If the developer has a listener that is executed before the one
LU> doing relocation, UIComponent.getClientId() call will not work
LU> correctly.
Leonardo goes on to propose a concrete solution to this apparent
implementation bug. I am having a hard time understanding the root
cause of the problem.
Is the root cause that we do not distinguish between Add/Remove events
done by the framework and those that happen at the request of
developers? This seems to be the what Leonardo is suggesting when he
says:
LU> The current behavior of Mojarra, from the point of view of the spec
LU> should be consider a bug. How to do fix it? I propose do the
LU> following for Mojarra:
LU> 1. Check when a component is temporally removed/added on
LU> ComponentTagHandlerDelegate implementation. If that so, disable
LU> event processing using FacesContext.setProcessingEvents() method
LU> temporally while removal and addition is done.
LU> 2. Propagate another internal event (for example
LU> PostAddToViewOnRefreshBuild or something like that) to notify the
LU> listeners used for relocation (cc:insertChildren, cc:insertFacet,
LU> h:outputScript, h:outputStylesheet) to do their job like before.
Do we have a testcase that reproduces this problem? Are any of the test
cases on JAVASERVERFACES-1826 showing this problem?
Can someone more clearly explain the actions Leonardo is suggesting we
take?
Ed
[1]
http://lists.jboss.org/pipermail/jsr-314-open-mirror/2011-January/000716.html
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 28 Business Days til JSF 2.2 Early Draft Review
| 64 Business Days til JSF 2.2 Public Review
| 152 Business Days til JSF 2.2 Proposed Final Draft