myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <>
Subject Re: [JSR-301] Need input from renderkits developers concerning namespacing
Date Wed, 13 Jun 2007 16:39:14 GMT
On 6/13/07, Scott O'Bryan <> wrote:
> Hey Renderkit guys.  We have an open question on the 301 EG regarding
> namespacing clientId's.  As you well know, Faces does not currently
> namespace it's client id's.  Although we're looking at asking that this
> be added to Faces 2.0, it's not in Faces 1.2.  We've discussed many
> options and the general consensus is that we want to try to do
> "something" automatically so that "simple" renderkits won't have to
> change in order to be compliant with Faces.  As we know though,
> Tomohawk, Tobago, and Trinidad are NOT simple renderkits.
> Of all the options we discussed on the 301 committee, we are looking at
> handling namespacing in one of two ways:
> 1. The first option is to have the Bridge implement some sort of custom
> Renderkit for the default renderkit such that the
> RenderKit.convertClientId method returns a namespaced client id.

convertClientId() is on Renderer, not RenderKit.   So
the change would have to apply to all Renderer implementations,
not all RenderKit implementations.

> issue with this is that there is concern that convertClientId is
> intended to change the format (ie. escaping, encoding, etc) of the
> clientId and not necessarily it's content.   So someone using
> getClientId in their application or renderkit currently would not have
> the "real" client id of the application.  We agree this is somewhat
> confusing.  Also, this would only work for the default renderkit.  If a
> renderkit had their own version of this object  (and I believe most all
> of them do), then they would need to add their own namespacing code).
> 2. The second option is to provide a special UIViewRoot and ViewHandler
> which, when running in a portal environment, would inject a naming
> container at the root of the component tree.  Therefore, using the
> normal faces mechanisms and the normal UIComponent.getClientId(), we
> would have the namespace appended to all children.  This, of course,
> would change the expected structure of the UIViewRoot and is more
> complex to implement.  Furthermore, if a renderkit overrides the
> ViewHandler and/or the UIViewRoot they would need special handling of
> this resource injection.  If we go this route there will be a number of
> API's provided by 301 to aid in this naming container injection, but
> renderkits would have to do the right thing for namespacing.
> So my question is, what do you guys prefer?  Would you prefer possibly
> having to modify some code in your Renderkit implementations or your
> ViewHandler implementations?  My preference would be #2 because I think
> renderkits are less likely to override the UIViewRoot and ViewHandler
> then they are to override the Renderkit.  And even though the code in
> here may be more involved for a renderkit developer, there is something
> appealing about having getClientId return the correct client id.

I'm not sure what's meant by "the correct client id", as my
definition of that term is "whatever is returned by

That said, #2 is a simpler and more practical option, IMO.

-- Adam

View raw message