[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008805#comment-13008805
]
Scott O'Bryan commented on PORTLETBRIDGE-196:
---------------------------------------------
Why do we need a separate FactoryFinder for this? Isn't it enough to use the
existing NavigationHandler factory? The reason I bring this up is that
Trinidad, as a renderkit, needs to be able to work both in a servlet
environment as well as a portlet environment where the bridge may not be
present. As such, I'd prefer to keep things as close to the origional JSF spec
as possible.. That said, I'm cool with a nav handler that supports the various
nodes. I'm just wondering why that would need to be different from the
original?
> Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler
> and associated BridgeNavigationHandlerFactory
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-196
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-196
> Project: MyFaces Portlet Bridge
> Issue Type: New Feature
> Components: General
> Affects Versions: 3.0.0
> Reporter: Neil Griffin
> Assignee: Michael Freedman
>
> This abstract class would define the contract for a brige-specific
> NavigationHandler that fortifies the JSF runtime with the ability to handle
> to-view-id entries in navigaion-case blocks that respect the
> Bridge.PORTLET_MODE_PARAMETER parameter for switching to a different
> PortletMode(s) and the Bridge.PORTLET_WINDOWSTATE_PARAMETER parameter for
> switching to a different WindowState(s).
> It would also have the ability to react to changes in portlet modes that were
> done programattically by portlet developers that called
> StateAwareResponse.setWindowState(WindowState) during the INVOKE_APPLICATION
> phase of the JSF lifecycle.
> Finally, this abstraction would remove the requirement for setting values on
> the ActionResponse in the ExternalContext.encodeActionURL(String) method as
> described in Spec section 5.4.2. Strictly speaking that method, is only
> supposed to return a value, and not take any underlying actions.
> Please refer to the following classes for this proposal:
> http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/application/BridgeNavigationHandler.java
> http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/application/BridgeNavigationHandlerFactory.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
