Gang -
The new ComponentModificationManager and ComponentManager APIs were
added at my request, as a result of this spec issue that I logged in 2011:
JAVASERVERFACES_SPEC_PUBLIC-984 Component context management
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-984
Ed bravely addressed my requirements (thanks Ed!) and asked me to review
on more than one occassion. As you can tell from my other recent
emails, I haven't had a chance to review anything until now.
I've got a variety of minor concerns about the proposed API that are
likely correctable with little effort.
However, I have one major concern that we are not going to be able to
address for 2.2. Let me try to explain that...
The goal of this API was to provide better integration between JSF's own
context management (eg. pushing and popping #{component} and #{cc}
values) with third party frameworks/components that perform similar
context management.
This requires that the JSF implementations actually leverage the new
component context management APIs for managing their own context. This
is not currently the case - ie. at the moment no code is actually taking
advantage of these new contracts, and the spec is silent on whether JSF
implementations are required to use this feature.
My feeling is that the only way that we can be sure that we've got these
APIs right is by enhancing the JSF implementations to use these APIs and
testing the results. Without this, these APIs are useless, and quite
possibly wrong.
Since we do not have time left to validate these APIs before 2.2 goes
final, I would like to request that we pull this feature from 2.2. That
is, I would like to ask that we kill:
- ComponentModificationManager
- ComponentModification
- FacesContext.getComponentModificationManager
Before 2.2 goes final.
Hopefully we can revisit this issue in 2.3, starting with investigating
what it would take for the JSF implementations to leverage a
publicly-spec'ed context mangement solution for their own context
management purposes.
Andy