Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete Portlet integration for Web Flow 2.x, including JSF + SWF integration in a Portlet environment. [SWF-183] #1100

Closed
spring-operator opened this issue Oct 5, 2006 · 7 comments

Comments

@spring-operator
Copy link
Contributor

spring-operator commented Oct 5, 2006

Keith Garry Boyce opened SWF-183 and commented

JsfPortletFlowController to allow jsf in portlet environment. Attached is controller


Affects: 2.0 M3

Attachments:

Issue Links:

@spring-operator
Copy link
Contributor Author

Keith Garry Boyce commented

This class should be included in webflow release if possible. I have tested it and it appears to work.

@spring-operator
Copy link
Contributor Author

spring-operator commented Feb 6, 2008

Martin Marinschek commented

Hi Keith, Keith,

I have taken a short look at the code, and I would highly recommend not going down a path where you try to create a new Spring-Webflow-Portlet -- JSF - Bridge. You should instead use the existing bridges in the market, as for example, the JSR-301 reference implementation. I actually liked the Webflow 1.0.5 loosely-coupled integration with JSF more - what were the specific problems which triggered you to move over to the new, deeper, up-front integration of exchanging the FacesServlet/Portlet? (note: I just read the related issue #1216, and now I know the issues - well, I think you have opened another can of worms with this new approach).

If you really want to do the portlet integration as outlined in the attached patches, I will still give you a few hints which might help you tracking down problems with this code:

  • obviously - there is a reference to com.sun.faces.* - you may not reference sun internal classes if you want your code to run with other JSF-implementations (or in this case bridges?) as well
  • there is obviously no code to handle the JSF view state to be available at the beginning of render-response - what will happen with this state; it will obviously not be restored from the session?
  • Request-Parameters set in the action-request are not available to the render-request - this might be a problem with many frameworks
  • the before restore-view callback on phase-listeners is not executed on the render-request - again, this might be a problem with many frameworks

If you find something that is considered, but I didn't see where, please feel free to correct me, however, I am sure there will be a host of other problems, which I ignored in the short time I looked at the code.

regards,

Martin

@spring-operator
Copy link
Contributor Author

spring-operator commented Feb 6, 2008

Keith Donald commented

Hi Martin,

We are not proceeding down a path where we try to create a new Portlet JSF Bridge. The approach we are taking uses the existing bridge infrastructure provided by the Spring Web Portlet MVC infrastructure. Specifically, a Portlet MVC Controller implementation adapts the Portlet world to the SWF world in a general manner (see the 1.0.5 SWF PortletFlowController for an example), and then JSF is managed specifically and entirely inside the SWF world from within the SWF ViewState (via the ViewFactory abstraction, introduced in #1216). We have enough information in the SWF ExternalContext to handle the Portlet render/action request semantics properly from within SWF, including the preserving of flow execution state across requests.

Can you elaborate on this? "Request-Parameters set in the action-request are not available to the render-request - this might be a problem with many frameworks " -- who would be setting such parameters, and how exactly? Of the four specifically points you made, this is the one I'm not entirely sure we have fully addressed. I'll certainly update this JIRA again as we progress or encounter concrete issues.

Thanks

@spring-operator
Copy link
Contributor Author

Martin Marinschek commented

Hi Keith,

I was using the wrong wording - request attributes was what I wanted to say. You might account for this already in saving/restoring the flow?

regards,

Martin

@spring-operator
Copy link
Contributor Author

Daniel Prado commented

Does anybody a complete example application of integration between JSF+JSF into a Portlet?

Because I try to integrate this framework in a portlet application, but I don't achieved my purpose.

I try to use the JsfPortletFlowController but I don't obtain any result. Always throws this exception: java.lang.IllegalStateException: No external context is bound to this thread.

@spring-operator
Copy link
Contributor Author

Scott Andrews commented

Portlet integration is available via org.springframework.webflow.mvc.portlet.FlowHandlerAdapter. This hooks into Spring Portlet MVC handlers, see org.springframework.web.portlet.handler.

The portlet request's WindowState and PortletMode are exposed via externalContext.getRequestMap().get("portletWindowState") and externalContext.getRequestMap().get("portletMode") respectively.

Two new sample applications are available as portlet versions of the booking-mvc and booking-faces sample applications. Both are designed to run under Apache Pluto 1.1.

alwaysRedirectOnPause should be turned off when in a portlet. If left on, the initial load of the portlet will not render any output.

@spring-operator
Copy link
Contributor Author

David Paterson commented

The sample JSF/Webflow/Portlet in the distribution is not deployable to either Pluto or Liferay, this issue should not be resolved. Have any recent efforts been made to integrate with Myfaces portlet bridge (JSR-301).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant