[jsr-314-open-mirror] [jsr-314-open] Proposal [868-DropCURRENT_COMPONENT CURRENT_COMPOSITE_COMPONENT]

[Kito Mann]

Hello Ed,

Couldn't you modify the map to return the constant values for the proper
keys? That way, they would be read-only values that don't need to be stored,
the Map just needs to know the keys.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17



On Tue, Aug 10, 2010 at 3:09 PM, Ed Burns <edward.burns at oracle.com> wrote:

> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=868
>
> Background:
>
> The JSF specification contains the following:
>
>    /**
>     * <p class="changed_added_2_0">The key to which the
>     * <code>UIComponent</code> currently being processed will be
>     * associated with within the {@link FacesContext} attributes map.</p>
>     *
>     * @see javax.faces.context.FacesContext#getAttributes()
>     *
>     * @since 2.0
>     */
>    public static final String CURRENT_COMPONENT =
> "javax.faces.component.CURRENT_COMPONENT";
>
>    /**
>     * <p class="changed_added_2_0">The key to which the
>     * <em>composite</em> <code>UIComponent</code> currently being
>     * processed will be associated with within the {@link FacesContext}
>     * attributes map.</p>
>     *
>     * @see javax.faces.context.FacesContext#getAttributes()
>     *
>     * @since 2.0
>     */
>    public static final String CURRENT_COMPOSITE_COMPONENT =
> "javax.faces.component.CURRENT_COMPOSITE_COMPONENT";
>
> The guarantee that the current and current composite components are
> available through FacesContext.getAttributes() doesn't seem right for
> several reasons:
> 1) It isn't useful.  The static methods
> UIComponent.getCurrentComponent() and
> UIComponent.getCurrentCompositeComponent() are more convenient and
> typesafe.
> 2) It is dangerous.  If the values of these attributes is set, the
> current stack will be messed up
> 3) When we aren't using the particular space-inefficient implementation
> the JSF RI currently uses, maintaining these attributes just in case a
> developer tries to request them is a waste
>
> Proposal
>
> Due to our iron-clad commitment to backwards compatibility, we keep the
> public static final String constants, but alter the behavior, providing
> a context-param to restore the old behavior.
>
> The constants will only be honored if the context param is set.
>
> Does this sound ok?
> --
> | edburns at oracle.com | office: +1 407 458 0017
> | homepage:          | http://ridingthecrest.com/
> | 06 work days until JSF 2.1 Milestone 2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100811/6ec5d4d4/attachment-0002.html