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
>
>
>
