osworkflow Api 之 loader部分

今天看osworkflow的感触就是，注释量太少，api也有好多方法不写是干什么的。实际代码中基本就没有多少注释，看起来很不方便。好多得猜。我过去和以后写代码绝对不会写成这样的。

com.opensymphony.workflow.ejb

这个包我暂时用不到，而且我对EJB现在还没什么发言权，所以就不写了。希望有谁能补充一下。

com.opensymphony.workflow.loader

这里包里主要包括两部分：descriptor和factory。还有一些其他如workflowloader、DTDEntityResolver、ValidationHelper、WorkflowSerializer、XMLUtil

 

先说说descriptor：

descriptor就是将平面的xml流转化为osworkflow内部所使用的具有真正意义的对象。

在一个工作流流转当中是通过AbstractWorkflow中的getWorkflowDescriptor(java.lang.String workflowName)来获取到实际代码中descriptor对象的。

如：WorkflowDescriptor wd =  wf.getWorkflowDescriptor(wf.getWorkflowName(id));

剖析descriptor结构

抽象类AbstractDescriptor。是其他所有相关descriptor的父类。

直接子类包括：ActionDescriptor, ConditionDescriptor, ConditionsDescriptor, FunctionDescriptor, JoinDescriptor, PermissionDescriptor, RegisterDescriptor, RestrictionDescriptor, ResultDescriptor, SplitDescriptor, StepDescriptor, ValidatorDescriptor, WorkflowDescriptor

在这里所有的子类中最主要的就是WorkflowDescriptor,怎么说呢，在众多descriptor中，除了abstractdescriptor，它好象就是个领袖，统管其他的descritor，到应该用哪个的时候，它就调用哪个。

如public FunctionDescriptor setTriggerFunction(int id, FunctionDescriptor descriptor) {

        return (FunctionDescriptor) timerFunctions.put(new Integer(id), descriptor);

}

这里实际用到的就是FunctionDescriptor

我想这些descriptor的每个里面的方法就不一一剖析了。大致通过名词就能够理解。如ActionDescriptor是针对Action的。在workflowdescriptor里有众多的get方法，想也可以想的到，即是get如step、function等等。除了这些get方法，另外一个比较特别重要的就应该是wirteXml了，即是实际写入xml过程定义文件。在这里应用到了XmlUtil。包括例如获取子元素节点以及缩写处理（printIndent）等

从设计模式角度看，这部分应用的是interpreter模式。

 

接下来解说factory：

如descriptor，有一个AbstractWorkflowFactory是其他factory的父类,包括XmlWorkflowFactory、UrlWorkflowFactory、JDBCWorkflowFactory，分别代表三种根据不同的过程定义方式，第一种是比较常用的写xml文件方式、第二种通过指定某一url，而第三种是数据库方式。下面是关于jdbc的工作流定义方式的注释。

/**

 * Workflow Factory that stores workflows in a database.

 * The database requires a property called 'datasource' which is the JNDI

 * name of the datasource for this factory.

 * <p>

 * Also required is a database table called OS_WORKFLOWDEFS with two columns,

 * WF_NAME which contains the workflow name, and WF_DEFINITION which will contain the xml

 * workflow descriptor, the latter can be either a TEXT or BINARY type.

 * <p>

 * Note that this class is provided as an example, and users are encouraged to use

 * their own implementations that are more suited to their particular needs.

 *

 * @author Hubert Felber, Philipp Hug

 * Date: May 01, 2003

 * Time: 11:17:06 AM

 */

其实不管哪种定义方式，实际定义的内容都是需要xml格式的，所以我觉得还是以xmlworkflowfactory是最容易理解最最常用的方式，需要提一下的是在spring和osworkflow结合的时候是使用的url方式的。

在xmlworkflowfactory中initDone方法中

String name = getProperties().getProperty("resource", "workflows.xml");

这里会按照指定的resource加载workflow的定义文件，如果没有才会以workflows.xml为默认。

  public boolean removeWorkflow(String name) throws FactoryException {

        throw new FactoryException("remove workflow not supported");

目前还不支持removeWorkflow。

Workflowloader

DTDEntityResolver： resolveEntity方法返回org.xml.sax.InputSource

 

Create a new input source with a byte stream.

Application writers may use setSystemId to provide a base for resolving relative URIs, setPublicId to include a public identifier, and/or setEncoding to specify the object's character encoding.

 

ValidationHelper:只有一个方法validate；判断给定的集合内的元素是否为com.opensymphony.workflow.util.Validatable的实例。

WorkflowSerializer：包括两个方法：generateWorkflowXML、initVelocity，第一个用来创建xml模板的，initVelocity买看懂，没注释。

XMLUtil：一些公用的xml操作，如获取某个指定元素，或者某个元素下面的所有子元素以及缩进处理、元素text 、编码处理（如html的尖括号），在实际操作xml当中都会引入此类。

WorkflowLoader：核心方法load(InputStream is, URL url)通过org.w3c.dom来加载传递进来的xml文件流或者url，只要把第二个参数赋值为null，即可通过指定流加载；而通过指定第二个参数url则可通过url方式来进行加载，。最终返回workflowdescriptor的对象。此外，此类还包含了一些异常处理。

 

更新中…………

yun15291li@hotmail.com欢迎交流！