📄 workflow.html
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Proposal - Workflow Management System</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta content="Craig R. McClanahan" name="author" />
<link href="../struts.css" type="text/css" rel="stylesheet" />
</head>
<body>
<div id="heading">
<a href="http://apache.org/">
<img id="asf_logo_wide" alt="The Apache Project" src="../images/asf_logo_wide.gif" />
</a>
<a href="http://struts.apache.org/">
<img id="struts-logo" alt="Struts Framework" src="../images/struts.gif" />
</a>
</div>
<!--end heading-->
<div id="content">
<div id="menu">
<p>Struts</p>
<ul>
<li>
<a href="../index.html">Welcome</a>
</li>
</ul>
</div>
<!--end menu-->
<div id="main">
<h2>Recent Developments</h2>
<div class="indent">
<p>
Work on this initiative has stalled.
It is recommended that interested parties look to the
<a href="http://jakarta.apache.org/commons/jelly/index.html">Commons Jelly</a> product.
A way to persist the workflow state between sessions is needed, but Jelly otherwise fills the needs
identified by this proosal.
</p>
</div>
<h2>Background and Goals</h2>
<div class="indent">
<p>Struts 1.0 has become an increasingly popular platform for constructing
web applications based on a Model-View-Controller type design pattern (also
known as the <em>Front Controller</em> pattern. It has achieved this
popularity for many reasons, but key among them have been:</p>
<ul>
<li>The simplicity of the basic organizational principles (once you
understand them)</li>
<li>The principle of <em>logical naming</em> to assist in isolating
the view layer and the model layer, so that changes in one do not
have to impact the other</li>
<li>A rich set of tools to assist in creating pages with dynamic content
exposed by the model layer through JavaBeans</li>
</ul>
<p>One consequence of the original Struts design, however, is that the
framework does not provide much assistance in organizing business
transactions that require more than one interaction with the user (i.e.
they span more than one JSP page and/or Action). Applications are left
to manage navigation issues, as well as deal with ActionForms whose
logical contents crosses page boundaries.</p>
<p>The original Struts design materially assists page designers in creating
dynamic pages, while protecting them from having to be very concerned with
the business logic -- other than the names of the JavaBeans used to
communicate model layer data to the presentation layer. However, Struts 1.0
still requires a Java developer to be involved on the business logic side
(even if all of the functional logic is already available in Java classes)
in order to create the Action classes.</p>
<p>The purpose of this <em>Workflow Management System</em> proposal is to
address some of these consequences. In particular, it intends to address
the following set of goals:</p>
<ul>
<li>Create a means where multiple-user-interaction business processes can be
configured (scripted), including support for conditional processing
and branching.</li>
<li>Support scripting elements that lets business application experts,
who are not necessarily Java developers, can integrate pre-existing
business functionality that is available as public methods on
arbitrary Java classes.</li>
<li>Assist page designers in creating the user interface elements that
correspond to navigation links within, or between, work flows.</li>
</ul>
</div>
<h2>Use Cases and Examples</h2>
<div class="indent">
<p>To give a flavor of what scripted workflow activities might look like,
it is useful to consider some possible use case scenarios. The
syntax that is shown for the examples should be considered as
illustrative of what should be possible, rather than normative.
No rigorous attempt has been made to guarantee consistency
between (or even within) these examples.</p>
<h3>Application Logon</h3>
<div class="indent">
<p>The example application included with Struts (like many other
web applications) uses application-managed security, including
a logon form. Consider that a business logic bean might be available
(in some scope under key <code>authenticator</code>)
that knows how to authenticate users given a username and password.
It could be utilized to script application logon like this:</p>
<pre>
<activity id="Application Logon">
<-- Display the logon form (web framework independent) -->
<web:forward id="display" page="/logon.jsp"/>
<-- Authenticate the username and password, returning a Principal
if accepted, or null if not -->
<web:set name="username" value="$parameter:username"/>
<web:set name="password" value="$parameter:password"/>
<core:invoke bean="authenticator" method="authenticate">
<core:param type="java.lang.String" value="$username"/>
<core:param type="java.lang.String" value="$password"/>
<core:return name="principal"/>
</core:invoke>
<-- If no Principal was returned, branch back to the logon form -->
<core:if expr="$principal == null">
<web:set name="error" value="$messages.lookup('invalid.logon')"/>
<core:branch idref="display"/>
</core:if>
<-- Exit to the "Main Menu" workflow -->
<core:goto name="Main Menu"/>
</activity>
</pre>
</div>
<h3>Simple Multi-Page Wizard</h3>
<div class="indent">
<p>Many complex data entry operations can be simplified (from the
user's point of view) by dividing them up into a series of simple
dialog pages that ask a few (often one) question that leads ultimately
to a completed set of information required to process a request.
In many cases, each page of the interaction will have navigation
controls so that the user can short cut to immediate execution,
or cancel the entire interaction. Such an interaction might be
modelled like this:</p>
<pre>
<activity id="Simple Wizard Application">
<!-- Display the first page of the iteration -->
<!-- (Using Struts-specific logical-to-physical mapping) -->
<struts:forward id="page1" name="Simple Wizard Page 1">
<!-- Process navigation input from the first page -->
<!-- (Can do something much like this framework-independently too) -->
<struts:navigate>
<struts:branch control="CANCEL" idref="cancel"/>
<struts:branch control="FINISH" idref="finish"/>
<struts:branch control="NEXT" idref="page2"/>
</struts:navigate>
<!-- Display the second page of the iteration -->
<struts:forward id="page2" name="Simple Wizard Page 2">
<!-- Process navigation input from the second page -->
<struts:navigate>
<struts:branch control="CANCEL" idref="cancel"/>
<struts:branch control="FINISH" idref="finish"/>
<struts:branch control="NEXT" idref="page3"/>
<struts:branch control="PREV" idref="page1"/>
</struts:navigate>
<!-- Display the third page of the iteration -->
<struts:forward id="page3" name="Simple Wizard Page 3">
<!-- Process navigation input from the third page -->
<struts:navigate>
<struts:branch control="CANCEL" idref="cancel"/>
<struts:branch control="FINISH" idref="finish"/>
<struts:branch control="PREV" idref="page2"/>
</struts:navigate>
<!-- Process the FINISH navigation control as appropriate -->
<xxx:yyy id="finish" .../>
<core:goto name="Main Menu"/>
<!-- Process the CANCEL navigation control as appropriate -->
<xxx:yyy id="cancel" .../>
<core:goto name="Main Menu"/>
</activity>
</pre>
<p>Not illustrated above, but also interesting to explore, would be
the situation where choices on one page affect whether some pages
in the overall flow might be skipped.</p>
</div>
</div>
<h2>User Visible Features</h2>
<div class="indent">
<p>Workflow system capabilities will be exposed to applications through
Java APIs that represent both the static description of particular
activities and the dynamic current state of a computation. Object
factory and pluggable implementation patterns shall be used where
appropriate to maximize the generality and flexibility of the system.</p>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -