Just fixing the subject line: ComponentManager -> ComponentModification.
Andy
On 3/12/13 9:56 PM, Andy Schwartz wrote:
> 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
>
>