With Roger's changes, I would suggest removing the bit about carrying
the previous renderkitId to the new UIViewRoot within
ViewHandler.createView(FacesContext,String).
We aren't always guaranteed to have a previous UIViewRoot when
createView is called, so we have logic that works 'sometimes'. I could
see making a case for carrying the locale, but a renderkitId is
something that will be declared at the application layer and to have
'exceptions' of renderKitIds 'sometimes' carry back into other parts of
the application is probably not the right choice.
-- Jacob
Jacob Hookom wrote:
> I'm not sure why that would occur since going back to page1.jsp via
> JSF would create a new component tree, the renderKitId would be null
> on this new component tree-- and according to the logic you described,
> it would be set to the default renderkit (HTML_BASIC).
>
> Roger Kitain wrote:
>
>> Change bundle posted at:
>>
>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=50
>>
>>
>> One interesting wrinkle...
>> If you've got an application:
>>
>> page1.jsp
>> <f:view >
>>
>> page2.jsp
>> <f:view renderKitId="CUSTOM">
>>
>> page1.jsp will default to HTML_BASIC
>> page2.jsp switches to CUSTOM
>> The renderKitId is now CUSTOM.
>> If there is a button on page2.jsp that transfers
>> control back to page1.jsp, the renederKitId is still CUSTOM.
>>
>> If an application is going to switch renderkits this way,
>> they should probably specify the renderKitId attribute in all pages.
>>
>> -roger
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
>
--
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com