OSWorkflow的Validators,Registers和Conditions[原]

三、OSWorkflow的Validators

与OSWorkflow的函数一样，OSWorkflow的validators也有三种不同的形式：Java-based, BeanShell和BSF。Java-based的Validators必须实现com.opensymphony.workflow.Validator接口（或者如果通过远程EJB的话，要实现com.opensymphony.workflow.ValidatorRemote接口）。在所有的Java-based validators中，都要抛出InvalidInputException异常。

但是在BeanShell 和 BSF的实现中，情况稍微有点不同，因为在scripts中抛出的异常无法在Java运行时环境中传播出去。为了达到这个目的，BeanShell或BSF所返回的值要作为错误消息返回，逻辑是这样的：

--如果返回的是一个InvalidInputException对象，那么这个对象会立即被抛出到客户端。

--如果返回的是一个Map，那么这个Map被用于InvalidInputException中的 错误/错误消息对。

--如果返回的是一个String[]，那么偶数值被用做关键字(key)，奇数值被用做所对应的值，这样就可以构造出上面的所述的Map。

--如果不是上面的三种情况，返回值将被转换为一个String对象，并且作为一个错误消息。

四、OSWorkflow的Registers

OSWorkflow中的Register是一个运行时的变量，它能够动态的注册到workflow的定义文件中。Registers在很多场合都是很有用的。例如：你想提供让workflow在它的描述符文件中就能访问一个实体的方法。这时，你就可以定义一个Register来封装这个实体。如果这个实体是一个本地的session EJB的话，你就要使用com.opensymphony.workflow.util.ejb.local.LocalEJBRegister注册类。例如，在后面的post-function中，你就可以访问这个实体，并且可以通过beanshell script来调用这个实体中的方法。

Registers也有三种实现方式：Java-based, BeanShell和BSF.

1. Java-based

Java-based registers 必须实现com.opensymphony.workflow.Register接口(或者如果是远程ejb的话，你要实现com.opensymphony.workflow.RegisterRemote接口)。

2. BeanShell and BSF registers

通过script返回的值或对象将是你注册的对象。

注：在registers的接口中，你只需要一个args Map参数就行了，这是因为registers的调用根本不管用户的输入。

3. 例子：

下面的例子将说明register的功能和用途。在这里register被用于一个简单的日志register，它有一个可访问的变量"log"，这个log变量可以在可以在整个工作流的生命期内被访问。日志记录器可以做很多有用的工作，比如说将工作流的实例id加入到日志记录中。我们在workflow的描述符文件的顶层定义register。

<registers>

    <register type="class" variable-name="log">

      <arg name="class.name">com.opensymphony.workflow.util.LogRegister</arg>

      <arg name="addInstanceId">true</arg>

    </register>

</registers>

从代码中可以看到，我们创建了一个名为log的LogRegister，还指定了一个值为true的参数addInstanceId。

我们可以在workflow描述符文件中的任何地方使用这个变量。例如：

<function type="beanshell" name="bsh.function">

  <arg name="script">transientVars.get("log").info("function called");</arg>

</function>

上面的函数将输出"function called"，同时在输出前附加了workflow的实例id。

五、Conditions

在BSF和Beanshell的script中，有一个特别的对象叫做"jn"。这个变量是com.opensymphony.workflow.JoinNodes类的一个实例，被用于join-conditions中。除此之外，conditions与functions的不同在于，conditions必须返回一个true或false的值。这个值可以是一个"true"或"false"的字串，也可以是一个"true"或"false"的布尔值，甚至是一个含有toString()的函数，其返回值为"true"或"false"的对象。

每个condition一定是作为一个conditions的子标签被定义的。当你使用"AND"类型，所有的condition标签的值必须都是"true"，整个conditions才能是true。否则，整个conditions将返回"false"。如果你使用"OR"类型，那么只要有一个condition标签的值为"true"，整个conditions就为true，而只有当所有的condition标签的值必须都是"false"，整个conditions才能是false。如果你想要更复杂的逻辑判断，那么你就要自己考虑使用Condition或ConditionRemote接口、BeanShell或者是BSF来实现。注意：如果在conditions标签中只含有一个condition的话，类型可以省略。

下面是OSWorkflow自带的一些标准的conditions：

  --OSUserGroupCondition - 使用OSUser来判断调用者是否在参数"group"中。

  --StatusCondition - 判断当前步骤的状态是否与参数"status"相同。

  --AllowOwnerOnlyCondition - 如果调用者是指定的步骤的所有者的话，那么只返回true，如果没有指明步骤的话，就返回当前步骤。

  --DenyOwnerCondition - 与AllowOwnerOnlyCondition功能相反。