[jira] Commented: (PORTLETBRIDGE-196) Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory

["Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>]

    [ 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