I did not want to join Spring forum until my own project supports Spring, but seeing this discussion related to JSF, I could not help posting a message.
Thinking about dialogs, I think of them from a desktop programmer point of view. In a desktop OS dialog is a window with one or several panels. If it is a notebook, than a user can select a page explicitly, if it is a simple dialog, then panels can be defined in a resource, and switched from the code simply by selecting visible panel ID.
Thus, a dialog is is not a usual flow of pages. I think, a dialog is an object which can have state and can visulalise itself depending on the state. Think portlets.
Trying to integrate my own component into JSF, I used the idea of stateful visual component, along with David Geary's tip of how to compose JSF page from subpages. So, I have "master" page ("dialog window frame") which includes "panels":
Code:
<html>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:view>
<jsp:include page="step1.jsp" />
<jsp:include page="step2.jsp" />
<jsp:include page="step3.jsp" />
</f:view>
</html>
Originally Posted by
bura
To introduce within the JSF application a more structured webflow, we propose to put a special page within the JSF application. Links are possible to this page and from this page, nicyly interconnecting the JSF and the webflow worlds.
Yep, kinda like this. The master page is the only location where client sends requests (for that dialog, or for the flow if you wish). Client either submits input to master page using POST, or loads master page using GET. In the latter case master page builds itself and shows the panel that corresponds to current state. Each panel looks something like this:
Code:
<html>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:subview id="step1" rendered="#{wizardBean.step1}">
<h:form id="page_step1" >
<h:messages />
<h:panelGrid columns="2" border="1" cellspacing="0">
<h:outputText value="User Name:"/>
<h:inputText id="userNameEdit" value="#{wizardBean.userName}"/>
<h:outputText value="Password:"/>
<h:inputText id="userPasswordEdit" value="#{wizardBean.userPassword}"/>
<h:commandButton action="#{wizardBean.cancel}" value="Cancel"/>
<h:commandButton action="#{wizardBean.Next}" value="Next"/>
</h:panelGrid>
</h:form>
</f:subview>
</jsp:root>
The important thing about code above is "rendered" attribute. Maybe I did not look well enough, but I could not create a full-blown expression like this rendered="#{wizardBean.currentStep.equals(1)} So, I am using a bunch of boolean methods, as many as many panels. Kinda ugly, but it works. Notice, that each included JSP contains subview.
The backing bean is simple and is not interesting, so it is not shown here. The faces-config.xml is actually more important:
Code:
<navigation-rule>
<from-view-id>/signup.jsp</from-view-id>
<navigation-case>
<from-outcome>reload</from-outcome>
<to-view-id>/signup.jsp</to-view-id>
redirect/>
</navigation-case>
</navigation-rule>
<managed-bean>
<description>
Signup Wizard bean
</description>
<managed-bean-name>wizardBean</managed-bean-name>
<managed-bean-class>com.superinterface.loginwizard.jsf.WizardBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
The navigation rule above along with composition of main page provides the functionality, that makes this dialog a control. This a very important concept. For a control, flow does not go from one page to another. Instead, the control is addressed by a single URL, and generates different pages ("panels") depending on its current state. Again, think portlets. Portlet is a control, dialog is a control, wizard is a multi-panel control.
First you navigate to master page signup.jsp (using GET), it includes subviews. Each subview checks the current dialog state. If state corresponds to a subview, the page it is included into master page. Then the master page is shown, now it contains panel which is synchronized with dialog state. When you click a button, an event triggers the method in the backing bean.
Backing bean updates the model and changes state if needed. Then it returns back, and JSF executes navigation rule. What it does? It goes back to itself, to the same master page. Then JSF loads master page again. State was changed, so a different subview is included according to "rendered" rule.
Originally Posted by
bura
[JSF] doesn't handle multiple submits or browsers back, forward and refresh buttons.
Notice <redirect/> tag in the navigation rule above, this helps to fight with POSTDATA problems and provides clean refresh. Current JSF version does not have a replacement for <controller nocache="true"/> that Struts has, but I was promised that non-cachable pages will be possible in the next version ;-)
This is basically it. The only part left is to define state transitions and to create panels.
Integrating SWF and JSF
Reply With Quote
