Three Workflow Approaches with WebLogic Portal
Each of the events has a portlet event handler registered to listen for it. The handlers can be in as many different portlet definitions as you want, allowing for reusing the methods in the same controller on different pages or be able to have several different controllers interact with each other through the event framework. Keeping your example simple, you will have the methods in one controller in a single portlet:
<netuix:portlet definitionLabel="eventBasedPageFlow" title="Event Based Page Flow"> <netuix:handleCustomEvent event="callDisplayBulletin" eventLabel="callDisplayBulletin" fromSelfInstanceOnly="false" onlyIfDisplayed="false" sourceDefinitionWildcard="any"> <netuix:activatePage/> <netuix:invokePageFlowAction action="callDisplayBulletin"/> </netuix:handleCustomEvent> <netuix:handleCustomEvent event="callChangePassword" eventLabel="callChangePassword" fromSelfInstanceOnly="false" onlyIfDisplayed="false" sourceDefinitionWildcard="any"> <netuix:invokePageFlowAction action="changePassword"/> </netuix:handleCustomEvent> <netuix:handleCustomEvent event="callPresentSurvey" eventLabel="callPresentSurvey" fromSelfInstanceOnly="false" onlyIfDisplayed="true" sourceDefinitionWildcard="any"> <netuix:activatePage/> <netuix:invokePageFlowAction action="presentSurvey"/> </netuix:handleCustomEvent> <netuix:titlebar/> <netuix:content> <netuix:pageflowContent contentUri="/portlets/ eventBasePageFlow/EventBasePageFlowController.jpf"/> </netuix:content> </netuix:portlet>
The above example is for the sake or brevity. It is far more likely that these events would be handled by multiple portlets either due to presentation considerations (such as going from a page full of portlets to a page with a single portlet) or logical separation of functionality (such as a survey controller, bulletin controller, and so forth).
In addition to custom events, page flow actions are events that also can be listened for, allowing for the possibility of completely changing the functionality of action by listening for it and adding additional or new behaviors. The combinations are endless and can often be changed with only a minor configuration update or a single line of code. This simplicity is key to agile methodologies and provides developers with a rapid way to add functionality on an as-needed basis.
Workflows are a common requirement for portals. Although the examples in this article revolved around a simple registration and login process, they were chosen for their commonality. Employment applications, freight logistics, legal document creation, supply requisitioning, and financial transactions are other common workflows that are often required within a portal. Those that are straightforward with little or no deviation are implemented easily with a simple page flow. Nested page flows provide a solution to complex workflows that need to interact and provide an opportunity for the reuse of common sub-flows when a project has well-defined requirements. For a more agile approach, listening for and calling events provides a flexible, loosely-coupled way to call portlet methods within and between controllers without having to know all of the specifics what future requirements may be.
About the Author
Scott Nelson is a Senior Principal Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.
Page 3 of 3