Definitely option 2) - invokeOnComponent won't work with convertClientId (convertClientId should IMHO be deprecated).
regards, Martin On 6/13/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
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 > > >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
