Oracle Application中有FlexField(弹性域)这个东西。在FlexField tables,数据存放于VARCHAR2类型的一列或多列中。不论是数字、日期、文本等,最终都会以VARCHAR2存放在table中。在OA Page中,这些VARCHAR2一般需要使用相对应的格式,比如日期、数字,以使用相应的验证机制,或者根据不同的地区转换成不同的格式。问题是,怎样在前后台中做数据类型转换呢?一个最简单的办法是使用OAF的FlexField Bean。但在一些情况下,使用FlexField Bean反而会不方便控制。甚或乎,明明跟随了OAF Developer Guide的方法,但总是用不了这个FlexField Bean。这时,只能手工地做这件事情了。
数据类型转换的基本原理很简单:把读写分离,或者说把前后台不同方向的数据流分开处理。
1. 传统情况
所谓传统情况,或者一般情况,就是数据库的列名是有实际意义的、明确的。比如,列名是EFFECTIVE_DATE,EO、VO中的属性名也会使用EffectiveDate。
我们会在VO中定义一个SQL语句。当进行操作时,OAF会把这个SQL语句封装,然后进行读写。比如:
SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.effective_date AS EFFECTIVE_DATE
, ExampleEO.employee_name AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10
当查询example_id = 100的记录,OAF会封装成这样子:
SELECT *
FROM (SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.effective_date AS EFFECTIVE_DATE
, ExampleEO.employee_name AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10) QRSLT
WHERE QRSLT.EXAMPLE_ID = 100
插入的时候也是类似的:
UPDATE (SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.effective_date AS EFFECTIVE_DATE
, ExampleEO.employee_name AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10) QRSLT
SET QRSLT.EFFECTIVE_DATE = <effective_date> -- OK
, QRSLT.EMPLOYEE_NAME = <employee_name> -- OK
WHERE QRSLT.EXAMPLE_ID = 100
总的来说,是将VO中的SQL语句封装成表格,然后外面包裹相应的操作。
2. FlexField的问题
而在FlexField的情况,列名是没有实际意义,或者说不明确的。FlexField存放数据的列名一般是ORG_INFORMATION1、PER_INFORMATION5之类。在VO中,这些名字可能会被替换为实际的用途,比如说ORG_INFORMATION1可能是一个Effective Date,那么在VO中的属性就会被命名为EffectiveDate。这个的mapping是在VO properties中设置的。
为了简化列名,本文把ORG_INFORMATION1、PER_ATTRIBUTE1等统称为information1。于是,在一个FlexField表格,VO的语句会是这个样子:
SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.information1 AS EFFECTIVE_DATE
, ExampleEO.information2 AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10
查询example_id = 100的记录,会生成以下的语句:
SELECT *
FROM (SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.information1 AS EFFECTIVE_DATE -- information1 is a VARCHAR2
, ExampleEO.information2 AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10) QRSLT
WHERE QRSLT.EXAMPLE_ID = 100
查询语句本身没有问题。但是在OA Page中,显示日期的item所属的类型一般会设成DATE,而上面的SQL语句查询结果的类型是VARCHAR2。于是,VO与PG上的的属性类型不管如何设置,都会在页面上方报错。此乃问题一。
UPDATE (SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.information1 AS EFFECTIVE_DATE -- VARCHAR2
, ExampleEO.information2 AS EMPLOYEE_NAME
FROM ExampleEO
WHERE ExampleEO.example_id > 10) QRSLT
SET QRSLT.EFFECTIVE_DATE = <effective_date> -- Error
, QRSLT.EMPLOYEE_NAME = <employee_name> -- OK
WHERE QRSLT.EMPLOYEE_ID = 100
在FlexField table中,information的类型是VARCHAR2,而effective_date的类型是DATE。类型的不匹配,就会引起错误,转到异常页。此乃问题二。
3. 从数据库到页面 (Table -> Page,从后台到前台)
为了解决这个问题,我们可以为每个在OA Page上非字符类型的属性,在VO中定义一个相应类型的transient属性。以transient属性作为中间媒介,在不同的地方调用转换函数,从而在前后台进行数据类型转换。
对于上面的例子,我们可以在VO中定义一个名为DispEffectiveDate的属性。这个属性数据类型设为DATE,Updatable设为always。由于这个属性没有映射到表格中的列,所以这也是一个Transient的属性。数据类型转换,则是在属性calculation的那一项,调用数据库的PL/SQL过程,进行从VARCHAR2到DATE的转换。最终,在VO的SQL中生成了以下的SQL语句(也可以使用Expert Mode进行编辑):
SELECT ExampleEO.example_id AS EXAMPLE_ID
, ExampleEO.information1 AS EFFECTIVE_DATE
, ExampleEO.information2 AS EMPLOYEE_NAME
, FND_DATE.CANONICAL_TO_DATE(ExampleEO.information1) AS DISP_EFFECTIVE_DATE -- Invoking data type conversion procedure here
FROM ExampleEO
WHERE ExampleEO.example_id > 10
其中,FND_DATE.CANONICAL_TO_DATE是Oracle自带的函数。这个函数把格式为'YYYY-MM-DD HH:MI:SS'的标准日期字符串(这种字符串也是Oracle FlexField使用字符串保存日期的标准格式),转换成Oracle数据库的Date类型。
而在OA Page上,显示的item中的View Attribute属性,只需要选择上述的DispEffectiveDate,则可以正常地显示出来了。有关日期的验证也可以如常使用。
小结:在VO的SQL中插入一个PL/SQL函数调用,把VARCHAR2类型的变量转换为DATE类型。在页面中则选择被转换后的VO属性。
4. 从页面保存到数据库(Page -> Table,从前台到后台)
把页面上的日期保存为标准日期字符串,方法也是类似的。唯一不同的地方是调用转换函数的地方。
在描述怎么转换之前,我们需要知道一点:在用户填写好表单,按提交按钮后,OAF首先会调用VORowImpl相应的setter方法,之后才会调用用户定义CO的ProcessFormRequest (PFR)函数。如果将数据类型转换函数放在AM或VOImpl中(这些转换函数使用setter来设置数据库中的值),在CO中用invokeMethod来调用它们,即使这些转换函数包含了异常的处理,假若用户如果再按多一次按钮,表单也会跳到成功的DialogPage(假设定义了DialogPage来提示成功)。
这个问题的原因是,OAF会在底层的某个地方调用ProcessFormData()函数。这个函数调用了一个名为setValue()的函数。在setValue()的函数中,首先会判定新值和旧值是否相等。如果相等,则会跳过所有的任务,直接返回。这样,写在VO或EO中的数据验证方法也不会被调用。这种新旧值相等的验证是写死在底层的代码中,开发者是无法设置的。
具体地说,假若业务上规定EffectiveDate的值不能在01-Jan-2000以前。当用户输入一个01-Jan-1999,第一次提交的时候,因为01-Jan-1999与null值不同,所以在setValue()会设置。而在设置的过程中,会进行验证,从而捕捉到异常。当用户马上按第二次提交,这时在VO中,DispEffectiveDate属性的值已是01-Jan-1999,和页面上的01-Jan-1999相同。所以setValue()不会再尝试设值,也不会做相应的验证,于是,非法的值就被保存了。
回到正题。刚才说到,OAF会先调用VORowImpl的setter方法。于是,数据类型转换可以写在VORowImpl方法中:
public void setDispEffectiveDate(Date value)
{
setEffectiveDate(dataTypeConversion(value));
setAttributeInternal(DISPEFFECTIVEDATE, value);
}
public void setEffectiveDate(String value)
{
setAttributeInternal(EFFECTIVEDATE, value);
}
其中,dataTypeConversion()是一个自己写的函数,它的定义如下:
private String dataTypeConversion(Date value)
{
// convert data type here
return <return_value>;
}
通过上面的方法,在设置DispEffectiveDate的值的同时,相对应的EffectiveDate属性的值也会被设置。当多种类型需要转换,还可以利用多态,复用dataTypeConversion()函数。
这里还有一个小细节需要注意。setEffectiveDate()的调用必须放在setAttributeInternal()之前。原因是,当setEffectiveDate()抛出异常,程序不会执行下面那一句setAttributeInternal()。就是说,在VO中,DispEffectiveDate这个属性的值依然是null,没被设置。那么,当用户再次提交,setValue()就会再次设值,并且调用VORowImpl的setter函数了。
小结:在VORowImpl中,添加数据类型转换函数。然后在transient属性的setter中,先于setAttributeInternal()调用前,调用数据库相应列属性的setter,利用数据类型转换函数转换类型并设值。
5. 总结
在一般情况下,OAF都会生成漂亮的属性名和函数名,函数异常也会处理得很好。但是当需要手工处理FlexField时,这些事情就需要手工做。
如果说OAF生成的代码所使用的方法是读写共用一个SQL语句,那么我们手工实现转换的时候,就需要将读和写的处理分离。
在VO的SQL中调用一个PL/SQL函数进行转换,并把这个转换的返回值显示到页面上,此乃读法;在VORowImpl中添加Java转换函数,并在页面显示属性的setter中首先调用,此乃写法。
6. 补遗
a) 如果用户使用的不是EO based的VO,而是PL/SQL based,那么也可以在相应的PL/SQL package中,添加转换方法。
b) 关于程序异常处理,也是需要额外处理。在一般情况下,属性名在EO、VO中是统一的,而在FlexField中则不是如此。故此需要额外的处理。关于这个问题,会另外用文章说明。