Adam,
Thanks for the input. Big help. You're right about the renderer kit
thing, I've been up working on this pretty late and it's all a mush at
this point. :) I totally agree that I don't even know if it's
practial to do that. They were talking about wrapping the renderers
coming out of the getRenderer method on the renderkit. But my gut
feeling is that's a terrible idea and would be pretty difficult to
implement this functionality for each renderer.
Scott O'Bryan
Adam Winer wrote:
On 6/13/07, *Scott O'Bryan* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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.
The
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
UIComponent.getClientId()".
That said, #2 is a simpler and more practical option, IMO.
-- Adam
