myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (PORTLETBRIDGE-196) Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory
Date Sat, 19 Mar 2011 18:10:29 GMT

    [ 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

Mime
View raw message