自定义表单设计思路
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
自定义表单设计思路
为了满足和现有工作流系统的耦合,在适当改动现有工作流的基础上,对自定义表单系统(包括与工作流相关)的设计做出如下的规划:
1. 基础功能模块:部门、角色、人员信息、班组、岗位(这些都可能是潜在的流程参与者)
在现有基础上适当扩展;
2. 权限管理:需要在操作权限的基础上增加字段权限和记录权限,也就是要实现表单权限、
记录权限、字段权限;
3. 表单基本信息:表单对应的表实体的定义、实体属性定义等等;
4. 可视化的表单定制工具:实现基于web的图形化表单设计器,争取做到可拖拽控件,
无需安装任何客户端控件;——难点为数据绑定,也就是页面元素与数据表字段的映射,另外动态数据存储结构问题、表间数据校验和计算、建立主从表的问题是难点;因此要建立相对应的样式库、脚本库、函数库、模板库等等。
5. 除了可视化表单定制工具外应有:表单加载、表单解析、表单数据处理和表单存储功能;
6. 设计出发点:争取为今后我们做系统实现以面向服务或面向流程的方式构建系统做准备
(即系统的运行已流程驱动或服务驱动),做到随需而变,使得将来的系统的维护不要停留在代码级的维护层面上;
7. 设计目标:我们开发出的自定义表单系统做到工作流和自定义表单松耦合实现为好,用
户自定义表单并能与工作流有效结合的工作流过程定义方法及工作流系统结构;
8. 整个表单系统的设计采用分层建模方法进行设计与开发,可以分为:
数据层建模、业务层建模以及表现层建模
9. 采用基于描述的方法来提高表单的可维护性、可扩展性以及灵活性,是否
通过采用XML
来描述表单数据模型、业务模型和表示模型需要讨论后确定(设计完成的表单
以XML形式保存到数据库指定表中);
10. 初步设想我们开发的自定义表单系统是基于XForms标准而非基于传统的HTML表单标
准,分类表单数据,行为与表示也需要在设计器中体现出来——表单模板+数
据,本质上是以XML为核心并且实现表单数据模型与表现层(表单格式)分离。
大致的建立表单步骤如下:
第一步:定义表单基本信息;
第二步:表单设计器数学模型的建立,表单设计器引擎是整个表单设计的核心;
第三步:通过表单设计器定义表单样式和所有字段详细信息;
第四步:定义对表单的各类基本操作(仅仅针对的是增、删、改、查的基本操作)。
在搞清楚工作流控制数据、工作流相关数据以及工作流业务数据的前提下,流程的配置主要为以下步骤:
第一步:创建流程角色;
第二步:对创建的系统用户分配角色;
第三步:创建流程(建立自动流程);
第四步:表单中绑定流程(动态加载工作流表单),将表单视为多个表单项的组
合,每一个表单项都是用户需要填写的内容,对表单项进行定义;
第五步:试运行流程。
表单系统相关模块以及将要实现的功能
第一个功能模块:表单管理分配
表单管理员是设计表单样式、确定表单审批流程和分配使用者的一种角色;建立表单管理员角色以及分配表单管理员权限(延用目前OA系统的角色权限管理和人员角色管理模块即可)。
第二个功能模块:表单基础信息
表单基础数据字典信息建立(延用目前只是管理中的通用参数维护,稍作修改),旨在维护通用参数类别以及各相应类别下的参数维护。
第三个功能模块:表单设计制作
主要的输入类型分文本框、标签、文本域、单选按钮、复选按钮、下拉列表框和扩
展控件
标签:只供显示不可编辑,故只有在设了初始值才有意义,可以设置字段的货币
符号大小写转换,该字段将显示货币符号大写。
文本域:较文本框多了一个垂直滚动条。
为多行显示;在操作设置中设置了该字段
为追加,调用表单发送协同时,在后续流程节点中对该字段有编辑权限的用户单击文本域字段可以弹出一输入页面,可以向该文本域中追加信息。
单选按钮和下拉列表框:都是从多个选择项中(即参数值)选出一个,只是展现形
式不一样,在后续设置时都需要指定所绑定的通用参数类型。
复选按钮:复选所有的项目都必须在表单制作时单个表示出来,且其前面设计一文
本框,可以进行勾选。
扩展控件:借助于选择器完成录入的一种方式,设置时需要指定所绑定的选择器,
目前我们大致可以提供了选择人员、选择部门、选择岗位、选择班组和选择日期这5种选择器。
计算字段设置仅对数字型数据项、文本框有效。
表示该数据项的值是通过其它数字
型数据项的计算所得。
例如,金额可以设为{单价} * {数量},总金额可以设为sum({金额}) 计算可以通过表单数据域、系统变量(预设的通用参数——系统变量不可删除和修改)。
通过如上图所示的表单定制工具进行设计,旨在画出表单单据的样式,设计后形成表单模板通过XML存储表单的展示,并生成相应的表单实体以及表单实体属性
(字段以及数据类型、长度等信息);表单定制工具的基本功能是:定义表单的数据结构和数据表现形式。
数据结构的定义是指表单中字段的信息:字段的个数、字段顺序、字段属性等。
数据的表现形式即表单的外观:数据排列、字体、标题等;考虑XML结构描述的
优势,编辑完成的后表单内容用XML文档来描述。
表单定制完成产生的XML文档还是保存在数据库中,分两个实体存储,一个是表单类型表,存储所有的空表单类型,一个是表单实例表即流程运行时产生的表单,这个实体按类型加时间加编号检索,具体的XML描述文档采用大字段格式作为实体的字段(也可以考虑采用XML 附件形式)。
表单分类进行存储:对新建的表单进行分类存储,以便于调用该表单模板
时方便查找,
比如可以分为管理类、行政类、技术类、销售类等等。
【特别说明】由于表单定制工具是一个独立的工具,系统运行时,还必须提供读取、解析、保存表单XML文档的程序模块。
在将来的设计中,表单运行时程序采用组件对象的方式提供,嵌入应用程序页面,并调用对象提供的方法处理表单。
对HTML初始表单模板进行解析。
转换模板格式为XHTML,利用XML工具解析该表单模板,对其中的表单控件进行分析标识,同时在数据库中动态生成数据表,存储表单记录。
模板存储和解析采用XML + XSLT方案解决
采用XML描述数据,XSLT定义XML数据显示格式。
通过XSLT来控制数据的显
示;查询数据库返回XML格式数据,将XML保存到数据库中,通过XSLT来解析XML
数据文件生成HTML代码,最终将HTML代码显示到前台页面中。
见如下图所示第四个模块:表单管理
数据项:表单名称、排序号、所属应用、所属人、表单状态(草稿、发布、引用)、制作时间。
表单所属管理(表单名称、所属人,其中所属人只能在表单管理中进行选择)以
及表单发布,新建的表单还需要进行表单发布(发布好之后的表单方可被调用),没
有发布的表单还可以进行修改,也就是草稿状态下的表单可以修改,不受限制,发
布状态下表单若已有数据,则不可以删减字段以及修改字段类型或缩减字段长度;
可以将没有被调用发送过协同的表单模板删除。
第五个功能模块:流水号设置
记得公司已经做过流水号设置的工作,可以参考或重新实现大致页面形式如下: 第六个功能模块:表单流程定义
通过调用相应的表单模板(发布好之后的表单模板),建立带有表单的流程模
板,设置各个节点表单单据的数据项编辑权限,生成表单流程模板;主要页面形式
大致如下:
定义流程节点、授权给节点的人员、一个或多个部门、岗位、组等节点
节点属性设置:主要是对相应的流程节点上设置所授权人对表单字段的操作权
限
(浏览、编辑、隐藏以及追加信息功能)
另外流程节点设计中考虑
操作类型分新增、修改、只读,这是对整张表单而言的,并非指数据项;所以,新增只能用于表单流程的起始节点,修改和只读只能用于表单流程的处理节点的结束节点。
数据值和显示值:前者表示在数据库中存放的值,后者表示在界面上展现的值。
数
据值必须设置,显示值可以不设置。
数据值和显示值都勾选时,其手工和系统变量必须成对选择,如数据值中选择系统
变量:登录人员ID,显示值中也必须选择系统变量:登录人员姓名。
第七个功能模块:流程表单使用
调用定义好流程的表单模板在OA办公系统中使用,完成表单单据的填写和提交审批
填写数据后形成相应的表单实例以及对应的表单数据。
第八个功能模块:表单查询设置
定义查询条件、确定列显的数据项,以及对使用者授权;
数据项:查询名称、查询授权人、查询描述、预设条件、预览形式,主要实现页面形式大致如下
表单查询名称、比单名称、查询授权用户(多选用户)查询描述、预置查询条件设置数据域:设置查询的数据标题,也就是在查询出的列表显示的对应的字段第九个功能模块:表单统计设置
定义统计条件、确定列显的数据项,以及对使用者授权;
数据项:统计名称、统计授权人、对应的统计表单、统计描述、统计类型、预设条
件、预览形式,主要实现页面形式大致如下:
第十个功能模块:表单记录查询
根据查询设置,被授权的用户或部门或岗位对设置好的相应查询的结果查看
第十一个功能模块:表单记录统计
元数据
目录[隐藏] 定义元数据的优点属性元数据的意义元数据列举元数据开发应用的标准化框架
定义
根据统计设置被授权的用户或部门或岗位对设置好的相应统计的结果查看
元数据最本质、最抽象的定义为:data about data (关于数据的数据)。
它是一种广泛存在的现象,在许多领域有其具体的定义和应用。
在数据仓库领域中,元数据被定义为:描述数据及其环境的数据。
一般来说,它有两方面的用途。
首先,元数据能提供基于用户的信息,如记录数据项的业务描述信息的元数据能帮助用户使用数据。
其次,元数据能支持系统对数据的管理和维护,如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。
具体来说,在
数据仓库系统中,元数据机制主要支持以下五类系统管理功能:(,)描述哪些数据在数据仓库中;(,)定义要进入数据仓库中的数据和从数据仓库中产生的数据;(,)记录根据业务事件发生而随之进行的数据抽取工作时间安排;(,)记录并检测系统数据一致性的要求和执行情况;(,)衡量数据质量。
在软件构造领域,元数据被定义为:在程序中不是被加工的对象,而是通过其
值的改变来改变程序的行为的数据。
它在运行过程中起着以解释方式控制程序行为的作用。
在程序的不同位置配置不同值的元数据,就可以得到与原来等价的程序行为。
在图书馆与信息界,元数据被定义为:提供关于信息资源或数据的一种结构化的数据,是对信息资源的结构化的描述。
其作用为:描述信息资源或数据本身的特征和属性,规定数字化信息的组织,具有定位、发现、证明、评估、此外,元数据在地理界,生命科学界等顶域也有其相应的定义选择等功能。
和应用。
元数据(Meta Data)是关于数据仓库的数据,指在数据仓库建设过程中所产生
的有关数据源定义,目标定义,转换规则等相关的关键数据。
同时元数据还包含关于数据含义的商业信息,所有这些信息都应当妥善保存,并很好地管理。
为数据仓库的发展和使用提供方便。
元数据是一种二进制信息,用以对存储在公共语言运行库可移植可执行文件(PE) 文件或存储在内存中的程序进行描述。
将您的代码编译为 PE 文件时,便会将元数据插入到该文件的一部分中,而将代码转换为 Microsoft 中间语言 (MSIL) 并将其插入到该文件的另一部分中。
在模块或程序集中定义和引用的每个类型和成员都将在元数据中进行说明。
当执行代码时,运行库将元数据加载到内存中,并引用它来发现有关代码的类、成员、继承等信息。
元数据以非特定语言的方式描述在代码中定义的每一类型和成员。
元数据存储以下信息:
程序集的说明。
标识(名称、版本、区域性、公钥)。
导出的类型。
该程序集所依赖的其他程序集。
运行所需的安全权限。
类型的说明。
名称、可见性、基类和实现的接口。
成员(方法、字段、属性、事件、嵌套的类型)。
属性。
修饰类型和成员的其他说明性元素。
元数据的优点
对于一种更简单的编程模型来说,元数据是关键,该模型不再需要接口定义语言 (IDL) 文件、头文件或任何外部组件引用方法。
元数据允许 .NET 语言自动以非特定
语言的方式对其自身进行描述,而这是开发人员和用户都无法看见的。
另外,通过使用属性,可以对元数据进行扩展。
元数据具有以下主要优点: 自描述文件。
公共语言运行库模块和程序集是自描述的。
模块的元数据包含与另一个模块进行交互所需的全部信息。
元数据自动提供 COM 中 IDL 的功能,允许将一个文件同时用于定义和实现。
运行库模块和程序集甚至不需要向操作系统注册。
结果,运行库使用的说明始终反映编译文件中的实际代码,从而提高应用程序的可靠性。
语言互用性和更简单的基于组件的设计。
元数据提供所有必需的有关已编译代码的信息,以供您从用不同语言编写的PE 文件中继承类。
您可以创建用任何托管语言(任何面向公共语言运行库的语言)编写的任何类的实例,而不用担心显式封送处理或使用自定义的互用代码。
属性
.NET Framework 允许您在编译文件中声明特定种类的元数据(称为属性)。
在整个 .NET Framework 中到处都可以发现属性的存在,属性用于更精确地控制运行时您的程序如何工作。
另外,您可以通过用户定义的自定义属性向 .NET Framework 文件发出您自己的自定义元数据。
有关更多信息,请参见利用属性元数据的意义扩展元数据。
说到元数据的意义,可以从其应用目的来谈的。
虽然做数据仓库言必称元数据,必称技术、业务元数据,但其到底用于何处,离开了目标去谈元数据,就发现元数据包含太多的东西,因为他是描述数据的数据嘛。
还是拿客户关系系统来比喻,这个系统维护客户信息当然是有目的的,是要用这些信息进行一些自动的流程处理、去挖掘一些客户潜在的价值、做好客户服务。
当然没有必要去维护客户的生命特征信息,诸如指纹、犯罪史等,这些信息跟客户关系管理的目标关系不大。
元数据也是如此,你可以将所有数据的结构、大小、什么时间创建、什么时间消亡、被那些人使用等等,这些信息可以延伸得太广,如果不管目标,而试图去建一个非常完美的元数据管理体系,这是一种绝对的"自上而下"做法,必败无疑。
[]
元数据列举
基于应用,可以将元数据分成以下的若干种。
数据结构:数据集的名称、关系、字段、约束等;
数据部署:数据集的物理位置;
数据流:数据集之间的流程依赖关系(非参照依赖),包括数据集到另一个数据集的规则;
质量度量:数据集上可以计算的度量;
度量逻辑关系:数据集度量之间的逻辑运算关系;
ETL过程:过程运行的顺序,并行、串行;
数据集快照:一个时间点上,数据在所有数据集上的分布情况;
星型模式元数据:事实表、维度、属性、层次等;
报表语义层:报表指标的规则、过滤条件物理名称和业务名称的对应; 数据访问日志:哪些数据何时被何人访问;
质量稽核日志:何时、何度量被稽核,其结果;
数据装载日志:哪些数据何时被何人装载;
[]
元数据开发应用的标准化框架
1、数字图书馆资源组织框架
2. 元数据开发应用框架
2.1 元数据的基本意义 Metadata(元数据)是“关于数据的数据”;
元数据为各种形态的数字化信息单元和资源集合提供规范、普遍的描述方法和检索工具;
元数据为分布的、由多种数字化资源有机构成的信息体系(如数字图书馆)提供整合的工具与纽带。
离开元数据的数字图书馆将是一盘散沙,将无法提供有效的检索和处理。
3. 元数据应用环境
3.1 Metadata的应用目的
(1)确认和检索(Discovery andentification),主要致力于如何帮助人们检索和确认所需要的资源,数据元素往往限于作者、标题、主题、位置等简单信息,Dublin Core是其典型代表。
(2)著录描述(Cataloging),用于对数据单元进行详细、全面的著录描述,
政府信息:GILS 数据元素囊括
地理空间信息:FGDC/CSDGM
数字图像:MOA2 metadata、CDL metadata、Open Archives Format、VRA Core、NISO/CLIR/RLG Technical Metadata for Images
档案库与资源集合:EAD
技术报告:RFC 1807
连续图像:MPEG-7
3.3 Metadata格式的应用程度
不同领域的Metadata处于不同的标准化阶段:
在网络资源描述方面,Dublin Core经过多年国际性努力,已经成为一个广为接受和应用的事实标准;
在政府信息方面,由于美国政府大力推动和有关法律、标准的实行,GILS已经成为政府信息描述标准,并在世界若干国家得到相当程度的应用,与此类似的还有地理空间信息处理的FGDC/CSDGM;
但在某些领域,由于技术的迅速发展变化,仍然存在多个方案竞争,典型的是数字图像的Metadata,现在提出的许多标准都处于实验和完善的阶段。
3.4 Metadata格式“标准化”程度问题
Metadata开发应用经验表明,很难有一个统一的Metadata格式来满足所有领域的数据描述需要;即使在同一个领域,也可能为了不同目的而需要不同的但可相互转换的Metadata格式。
同时,统一的集中计划式的Metadata格式标准也不适合Internet环境,不利于充分利用市场机制和各方面力量。
但在同一领域,应争取“标准化”,在不同领域,应妥善解决不同格式的互操作问题。
4. 元数据结构
4.1 总体结构定义方式一个Metadata格式由多层次的结构予以定义:
(1)内容结构(Content Structure),对该Metadata的构成元素及其定义标准进行描述。
(2)句法结构(Syntax Structure),定义Metadata结构以及如何描述这种结构。
(3)语义结构(Semantic Structure),定义Metadata元素的具体描述方法。
4.2 内容结构
内容结构定义Metadata的构成元素,可包括: 描述性元素、技术性元素、管理性元素、结构性元素(例如与编码语言、Namespace、数据单元等的链接)。
这些数据元素很可能依据一定标准来选取,因此元数据内容结构中需要对此进行说明,例如MARC记录所依据的ISBD,EAD所参照的ISAD(G),ICPSR所依据的ICPSR Data Preparation Manual。
4.3 句法结构
句法结构定义格式结构及其描述方式,例如元素的分区分段组织、元素选取使用规则、元素描述方法(例如Dublin Core采用ISO/IEC 11179标准)、元素结构描述方法(例如MARC记录结构、SGML结构、XML结构)、结构语句描述语言(例如EBNF Notation)等。
有时,句法结构需要指出元数据是否与所描述的数据对象捆绑在一起、或作为单独数据存在但以一定形式与数据对象链接,还可能描述与定义标准、DTD结构和Namespace等的链接方式。
4.4 语义结构语义结构定义元素的具体描述方法,例如描述元素时所采用的标准、最佳实践(Best Practices)或自定义的描述要求(Instructions)。
有些元数据格式本身定义了语义结构,而另外一些则由具体采用单位规定语义结构,例如Dublin Core建议日期元素采用ISO 8601、资源类型采用Dublin Core Types、数据格式可采用MIME、识别号采用URL或DOI或ISBN;
又如OhioLink在使用VRA Core时要求主题元素使用A&AT、TGM和TGN,
人名元素用ULAN。
5. 元数据编码语言与制作方式
5.1 元数据编码语言
元数据编码语言(Metadata Encoding Languages)指对元数据元素和结构进行
定义和描述的具体语法和语义规则,常称为定义描述语言(DDL)。
在元数据发展初期人们常使用自定义的记录语言(例如MARC)或数据库记录结构(如ROADS等),但随着元数据格式的增多和互操作的要求,人们开始采用一些标准化的DDL来描述元数据,例如SGML和XML,其中以XML最有潜力。
5.2 元数据制作方式
(1)专门编制模块(例如对MARC、GILS、FGDC等)
(2)数据处理时自动编制(例如对Dublin Core等)
(3)数据物理处理时自动编制(例如数字图像扫描时的某些元数据参数)
(4)共享元数据(例如OCLC/CORC、IMESH
6. 元数据互操作性
6.1 元数据互操作性问题
由于不同的领域(甚至同一领域)往往存在多个元数据格式,当在用不同元数据格式描述的资源体系之间进行检索、资源描述和资源利用时,就存在元数据的互操作性问题(Interoperability):
多个不同元数据格式的释读、转换和由多个元数据格式描述的数字化信息资源体系之间的透明检索。
6.2 元数据格式映射
利用特定转换程序对不同元数据元格式进行转换,称为元数据映射(Metadata Mapping/Crosswalking)。
目前已有大量的转换程序存在,供若干流行元数据格式之间的转化,例如Dublin Core与USMARC; Dublin Core与EAD
Dublin Core与GILS; GILS与MARC TEI
Header与MARC FGDC与MARC
也可利用一种中介格式对同一格式框架下的多种元数据格式进行转换,例如UNIverse项目利用GRS格式进行各种MARC格式和其它记录格式的转换。
格式映射转换准确、转换效率较高。
不过,这种方法在面对多种元数据格式并存的开放式环境中的应用效率明显受到限制。
6.3 标准描述框架
解决元数据互操作性的另一种思路是建立一个标准的资源描述框架,用这个框架来描述所有元数据格式,那么只要一个系统能够解析这个标准描述框架,就能解读相应的Metadata格式( 实际上,XML和RDF从不同角度起着类似的作用。
XML通过其标准的DTD定义方式,允许所有能够解读XML语句的系统辨识用XML_DTD定义的Metadata格式,从而解决对不同格式的释读问题。
RDF定义了由Resources、Properties和Statements等三种对象组成的基本模型,其中Resources和Properties关系类似于E-R模型,而Statements则对该关系进行具体描述。
RDF通过这个抽象的数据模型为定义和使用元数据建立一个框架,元数据元素可看成其描述的资源的属性。
进一步地,RDF定义了标准Schema,规定了声明资源类型、声明相关属性及其语义的机制,以及定义属性与其它资源间关系的方法。
另外,RDF还规定了利用XML Namespace方法调用已有定义规范的机制,
6.4 数字对象方式
建立包含元数据及其转换机制的数字对象可能从另一个角度解决元数据互操作性问题。
Cornell/FEDORA项目提出由加快研究有效利用元数据进行检索(包括异构系统透明检索)、相关性学习、个性化处理等的机制。
加快研究元数据与数字对象和数字化资源体系有机整合的途径与方法。
推进研究利用元数据进行基于知识的数据组织和知识发现。