Java Reference
In-Depth Information
If the client code is responsible there is no guarantee that the access
restrictions will be observed and in addition this makes the client code
complex. If the
WfProcessImpl
class is responsible, then all the management
of the context is concentrated in that class, but the class is more complex.
Finally if the
WfActivityImpl
class is responsible, the access restrictions that
concern an activity are kept together with the rest of the activity-related
code. This makes the process class simpler and the activity class more
complex. We prefer this last option because we think it best concentrates all
the code related to the activities in a single class.
The handling of the workflow data requires only some changes to the JSP
developed in the previous prototype. The
WorkItem
page must present the
data visible to the activity while the
Complete
page must be able either to
store an update to the data or to complete the activity.
21.7.3
Implementation
The class
WfProcessDefinition
, in addition to the tag already implemented,
must be able to load the definitions of the workflow data. This is accom-
plished by adding a
Map
object that stores the
WfDataDefinition
instances
and adding a loop that reads all the elements with the
DATA
tag. An analogous
loop is required in the
toXML()
method to generate the tags.
package
ProcessDefinition;
...
public class
WfProcessDefinition {
...
Map data
#
new Hashtable();
// build a process definition from the corresponding XML
// element
public
WfProcessDefinition(Element process){
. . .
//Data
NodeList dats
#
process.getElementsByTagName
(WfDataDefinition.TAG);
for
(i
#
0; i<dats.getLength();
!!
i){
Element d
#
(Element)dats.item(i);
WfDataDefinition dd
#
new
WfDataDefinition(d);
data.put(dd.id,dd);
}
}
public
Element toXML(Document doc){
. . .
// Data
it
#
data.values().iterator();
while
(it.hasNext()){
WfDataDefinition d
#
(WfDataDefinition)it.next();
process.appendChild(d.toXML(doc));
}
