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.
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.
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).
Keith Garry Boyce opened SWF-183 and commented
JsfPortletFlowController to allow jsf in portlet environment. Attached is controller
Affects: 2.0 M3
The text was updated successfully, but these errors were encountered: