表单格式
目录
概述 2
表单映射 3
方式1 3
方式2 3
表单创建 5
主子表单 5
计算字段 6
选项级联填充 7
这里所说的表单与数据库中的表与UI中的数据窗体是不同的概念
数据库中的表提供了数据结构的描述,数格式的基本验证,同时提供了数据的物理存储.
UI中的数据窗体提供了数据的UI具体风格展现,有可能同时在代码中对数格式验证与业务逻辑做出控制.
而我说的表单提供了详细数据结构的描述,完整的数格式验证,具体的UI展现描述,完整的业务逻辑关系,以及业务权限
举例子说明一下:
1.在数据库中的表中只能描述某个字段是必填还是可空,在表单中对这个字段的描述是[什么身份在那个业务的那个步骤对这个字段是必填的]
2.在UI中的数据窗体中,某个字段被描述为文本框或下拉框.而在表单中,对数据展现的描述是X,Y,Z,Width,Height,UIType等.并且数据可以拥有多套不同的展现,在[什么身份在那个业务的那个步骤对这个字段是故什么时该展现成什么样子]也有描述.
表单的展现不依赖具体的UI技术,表单会提供UI展现器,用以动太的将数据展现成Html,WinForm,Asp.net,WPF,Silverlight等UI.
表单不提数据的物理存储功能,表单需要将自身映射到数据库的物理表中.通常会用如下两种方式映射
表单A
|
映射-> |
表A
|
||||||||||||||||||||||||
表单B
|
映射-> |
表单B
|
表单A
|
映射-> |
表
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
表单B
|
注意,上面的描述只是数据结构的抽象,实际上为了提高查询效率,我对结构做了调整,不过原理就是这样
在我以前的三个版本的工作流中只提供了[方式2]的表单模式,[方式1]需要自已去实现,本版本两种方式都提供了,并且将[方式2]作为默认模式,
原因如下,企业应用发展到现在,很多企业已拥有了上为了上为很多业务系统,如果为了上工作流平台,将原有的系统废除重做是得不偿失的.所以本次平台升级提供了将流程真接映射到其他业务系统业务表的功能.如果原系统的数据UI名称与数据库表的字段名称一致的话,你甚至可以直接用原系统的页面运行流程,注意,要使用该功能需要做如下设置:
注意,光这样是不行的,你还得在原系统中添加一个控制接口
事实上,在设计这个平台之初就考虑了与其他系统的集成,如果你已经有了一个人力资源系统,你就不需要在本系统中重建组织机构,可以设置映射从人力资源系统同步数据,你可以选择单向或双向同步
表单支持基于表生成,同时也支持基于表单生成表
表单可以来自一张表,也可以来自多张表,同一张表可以有多个表单.
表单支持一对多,一对一的主子表单
如
表单A1
|
映射-> |
表A
|
|||||||||||||||||||||
表单A2
|
如
表单A
表单A-Item
|
映射-> |
表A
表A-Item
|
表单支持计算字段:
方式1
rowID |
A |
B |
c |
X |
Y |
001 |
1 |
2 |
3 |
6 |
2 |
A+B+C |
(B-A)*2 |
||||
002 |
4 |
5 |
6 |
16 |
3 |
A+B+C +1 |
(B-A)*2 +1 |
方式2
rowID |
X |
Y |
001 |
6 |
2 |
A+B+C |
(B-A)*2 |
|
002 |
16 |
3 |
A+B+C +1 |
(B-A)*2 +1 |
rowID |
key |
value |
001 |
A |
1 |
001 |
B |
2 |
001 |
C |
3 |
002 |
A |
4 |
002 |
B |
5 |
002 |
C |
6 |
每行的同一字段可以具有不同的的公式,公式可在运行时动态选择与修改,[方式1]的公式只能用(A,B,C)构建,[方式2]的公式可以任意添加参数.
假设有如下数据
faultCategory |
faultCategoryNo |
A |
001 |
A |
002 |
B |
003 |
B |
004 |
faultCategoryNo |
faultPlansName |
001 |
1234 |
001 |
abcd |
002 |
5678 |
002 |
efgi |
需要如下效果
注意:选项级联填充,支持无限的链式传递,但不支持多触发,也就是当在A下拉框选择了某项后,A,C下拉框选根据不同的设置分别加载选择项.
要实现这个功能并没什么难度,只是当时设计时将这程需求忘了,现在要加上需要将触发目标由属性升级成集合.现在这个个模块级基本定版,我正在开发其他模块.所以这个功能就以后升级吧