myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <darkar...@gmail.com>
Subject Re: [JSR-301] Need input from renderkits developers concerning namespacing
Date Wed, 13 Jun 2007 19:09:13 GMT
That's a good point Martin.  InvokeOnComponent is not something we 
discussed but totally should have.  The initial spec for this changed at 
the last minute (from option 1 to option 2) and I don't think everything 
was taken into account.  We had some issues right off (of course) when 
someone was playing around with getting this to work with Trinidad and 
it blew up right away.  Consensus seems to be that we should go back to 
our original solution in the spec.

BTW- In case any of you are interrested, there is an Early Draft of 
JSR-301 on the JCP.ORG website if you want to take a look.  It's pretty 
rough and we'll be releasing one with many problems fixed in a couple of 
weeks (that was was hurried in order to make JavaOne).  But I would 
totally welcome any comments anyone might have so I can bring them up to 
the EG.  This project is extremely difficult because we're like an egg 
between two rocks.  :)  So the easier we can make it on app developers 
and renderkit developers alike, the better.

Scott

Martin Marinschek wrote:
> Definitely option 2) - invokeOnComponent won't work with convertClientId
> (convertClientId should IMHO be deprecated).
>
> regards,
>
> Martin
>
> On 6/13/07, Scott O'Bryan <darkarena@gmail.com> 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* <darkarena@gmail.com
>> > <mailto:darkarena@gmail.com>> 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
>> >
>> >
>> >
>>
>>
>
>


Mime
View raw message