基于Web的可配置信息发布收集系统-毕业论文

本科毕业论文本科毕业论文 (科研训练、毕业设计) 题题 目：基于目：基于 WebWeb 的可配置信息发布收集系统的可配置信息发布收集系统 姓 名： 学 院：软件学院 系： 专 业：软件工程 年 级： 学 号： 指导教师（校内）： 职称：教授 指导教师（校外）： 职称： 年 月 日 Web 下的可配置信息发布收集系统 2 基于 Web 的可配置信息发布收集系统 摘要 随着网络技术的不断发展，基于 Browse/Server 架构的 Web 应用系统被各行业广泛 应用。在各种信息化平台中，信息发布、收集乃至统计系统是一个重要的组成部分，它所采 取的方式及其遵循的模式直接影响了信息化平台的运作效率和执行质量。当前，在大量数据 需要进行收集和发布的情况下，原有的系统模式已经不能满足信息发布收集多、变、快、准 的要求。开发新的 Web 下的可配置信息发布收集系统成为各行业信息化过程中迫切需要解决 的问题。 本文针对以上需求，提出了 Web 下可配置信息发布解决方案，并以高校信息化平台为背 景，设计、实现了一个面向高校的基于 B/S 构架的可配置信息发布、收集系统。 文中首先分析了现有高校信息发布、收集方式的不足，并论述了新的解决方案，加以比 较。随后介绍了新方案中涉及的 ASP.NET、XML、面向对象语言、系统分层架构等技术。本 文第四章中，详细介绍了基于 Web 的以 XML 为驱动的信息发布、收集系统的实现。对该系统 进行了系统需求分析、流程分析、数据库设计和用户界面设计，并实现了其中的主要模块。 论文所使用的分析及设计过程，具有相当的普遍性，可以应用到其他基于 Web 的信息发 布、收集、统计系统开发中。 关键词 可配置 动态表格 信息收集统计 A Xml Web 下的可配置信息发布收集系统 3 Online Reporting Information System Abstract With the rapid development of Internet, web system based on browse/server is wildly applied in many fields. As an important part, reporting system has great influence on the web system efficiency and speed. How to build a flexible and credible dynamic reporting system by making use of the up-to-date Internet programming technique has become the hot issue in computer field. A dynamic reporting system should have at lease three functions: 1.designing and configuring reports on the website by IE or other browses 2.saving user interface information of the dynamic reports so as to reload it at anytime 3.saving data information of reports submitted by different users This dissertation designs a dynamic reporting system based on B/S under the background of high school information system. Firstly, it discusses the strongpoint of the dynamic reporting system compared with traditional reporting system. Secondly, it introduces such techniques as ASP.NET, XML, Object Orientation Programming and 3-tier architecture. The forth Chapter of the dissertation designs a dynamic reporting system by use of the combination of XML and ASP. NET techniques, completes system analysis, and implements parts of main functions. Key Words Dynamic report; Configurable; Information; A; Xml Web 下的可配置信息发布收集系统 4 目录目录 第 1 章引言5 1.1研究背景 5 1.2研究目的与内容 5 1.3系统整体框架 7 1.4本文组织 7 第 2 章系统背景8 2.1高校信息化概述 8 2.2现有高校信息发布、收集解决方案 9 2.3本文提出的解决方案 .11 第 3 章系统所涉及的技术及其概述.13 3.1面向对象的分析和设计 .13 3.2分层架构 .13 3.3XML 技术 .14 3.4ASP.NET 技术 .14 第 4 章基于 WEB 的以 XML 驱动的信息发布、收集系统构建.15 4.1系统开发与运行环境 .15 4.2系统需求分析 .15 4.3业务流程分析 .16 4.4数据库设计 .17 4.5界面设计 .24 4.6模块实现 .25 4.7系统页面功能描述 .33 第 5 章结论.36 5.1系统存在的不足 .36 5.2展望 .36 Web 下的可配置信息发布收集系统 5 第 1 章 引言 1.1 研究背景 随着信息时代的到来，网络正在加快渗透社会各行各业的步伐，现今的技术彻底改变 了“时空”的概念，使信息得以充分利用。作为 Intranet 的一个重要组成部分，信息管理 系统也起着很大作用，在 Internet 盛行之前，信息管理系统已广泛地应用于各行各业中， 在各企事业单位的行政管理中，使各项日常事务处理走向自动化、系列化、规范化、标准化， 大大提高了工作效率，己被越来越多的人门所认识。 在形式繁多的 Web 管理系统中，无一例外涉及到各类信息的发布、收集、反馈乃至统计 分析。数据如何在发布者和用户之间流畅传递，并能保持实时性、高准确度和高度自动化， 已经成为 Web 管理系统的一个难题。纵观现有的网上报送资料，大多数还停留在静态的网上 收集数据状态通过网页的静态表格填报，或提供下载表格，然后再通过电子邮件或以纸 张的方式报送给信息发布部门。这种方式虽然减少了外勤工作，但是所收集的资料还需要相 关部门的人员手工再次录入到数据库中。这样不仅容易出错，还非常费时，因此为避免出错 而增加复核引致的工作量并未减少。比如中国国家统计局及其全国各地的统计部门，无论是 企业网上收集统计资料还是下级统计部门向上级统计部门报送统计数据均使用这种静态方式 报送1。这样的工作流程造成了信息发布部门和信息提交者之间的双重困难，失去了 Web 应用开放性、广泛访问性、灵活性的优势。 1.2 研究目的与内容 本文作者身处高校，深切体会了高校信息化平台带来的各种便利。但同时也对该平台下 信息发布、收集的陈旧方式深感缺憾。因此本文以厦门大学高校信息化平台下的信息发布、 收集子系统为切入点，阐述了基于 Web 下 XML 驱动的可配置信息发布收集系统的提出、设计 以及实现过程，并将其实施于作者所在的厦门大学信息化建设项目组的科研管理系统中。厦 门大学科信息化建设项目组成立于 2004 年 5，作者有幸参加其中科研管理系统的开发。该 开发小组由 7 人组成。其组织结构如图 1.1 所示。作者负责信息发布收集子系统的开发。 Web 下的可配置信息发布收集系统 6 图 1.1科研管理系统的开发小组组织结构 可配置信息发布收集系统开发的目的是改现有手工、半自动数据上报、收集、统计模式 为统一的基于 Web 的动态发布、自动生成、可配置管理模式。达到数据发布收集的自动化、 系列化、规范化、标准化。 数据录入收集的理想状况，是在有新的数据需要收集的时候，由非技术人员通过易用的、 基于 Web 的图形界面来配置数据录入页面，然后将页面分配给不同的用户或用户群体。这样 的数据录入系统便可以解决静态方式报送带来的问题，同时具备更多的优点,比如: 1. 数据录入页面可以由非技术人员来配置和分配。 2. 非技术人员可以对数据录入页面进行管理。 3. 用户在登陆系统以后便可以知道自己需要填写哪些页面提交信息，而不必去查询自 己需要提交哪些页面。 4. 系统可以应付所有的数据录入的变化，不论是用户界面上的变化，还是具体数据内 容的变化，系统都可以在运行的时候进行配置和修改。 基于这样的思路，系统的整体构架和主要界面如下所述。 Web 下的可配置信息发布收集系统 7 1.3 系统整体框架 图 1.2 系统整体示意图 1.4 本文组织 本文在结构上将做如下的安排： 第一章介绍了系统的研究背景、研究目的及研究内容，简要概述了系统整体构架。 第二章分析现有信息发布收集的不足，并提出本文的核心Web 下可配置信息发布收集 解决方案，加以比较，论述其可行性。 第三章介绍新方案中涉及的 ASP.NET、XML、面向对象语言、系统分层架构等技术。 第四章详细介绍了基于 Web 的以 XML 为驱动的信息发布、收集系统的实现。对该系统进 行了系统需求分析、流程分析、数据库设计和用户界面设计，并实现了其中的主要模块。 第五章全面总结本文所阐述的方案和系统，实现的意义及发展趋势。分析该解决方案存 在的问题，并就提出的问题给出了分析和改进方案。 Web 下的可配置信息发布收集系统 8 第 2 章 系统背景 2.1 高校信息化概述 校园综合信息平台是以网络为基础，利用先进的信息化手段和工具，实现从环境（包括 设备、教室等）、资源（如图书、讲义、课件、信息等）、到活动（包括教、学、管理、服 务、办公等）的全部数字化，在传统校园的基础上构建一个数字空间以拓展现实校园的时间 和空间维度，从而提升了传统校园的效率，扩展了传统校园的功能，最终实现教育过程的全 面信息化。 校园综合信息平台建设是分阶段、分层次的，它经历的是由硬到软、由下而上、螺旋上 升的建设过程。校园综合信息平台也是一个层次化的结构，其体系结构可以用一系列同心圆 表示，内圆是核心，是基础，外圆是在内圆的基础上提供的更进一步的服务。按照功能划分， 校园综合信息平台可以分为六层，其结构图如图 2.1 所示： 图 2.1 校园综合信息平台的分层结构 其中的基础信息服务是信息流动的软件基础，包括 SMS 校园通、电子邮件、文件传输、 信息发布、域名服务、身份认证、目录服务、安全服务、计费管理等；而本文所提出的动态 可配置信息发布收集系统正是处于这个层面。 Web 下的可配置信息发布收集系统 9 2.2 现有高校信息发布、收集解决方案 2.2.1 现有信息发布、收集方式 在开发数据驱动的 Web 信息系统的时候，常见的 Web 页面会是用户进行数据录入的页 面。开发特定的数据录入页面的时候，通常是从需求分析开始，需要知道系统需要向用户收 集何种信息，然后根据需求设计 Web 页面，包括创建 Web 图形界面以及所必须的数据库操作 代码，必要的时候还要为此页面的信息设计数据库中的表结构。 当数据录入页面的需求事先已知并且对系统所有的用户都一致的时候，开发这样的数 据录入页面是十分简单的任务。然而，当需要动态的数据录入页面，而且从 Web 图形界面到 数据库的保存都需要动态可配置的时候，任务就变得艰巨起来。例如，某一时期，学校需要 教师提交一系列的报表，报表的格式以及内容是经常变化的，并且不同的教师或不同类型的 教师需要录入的数据不一样。 在通常情况下有两种方式可以解决： 1. 为每一个数据录入做不同的 Word 文档，让教师在网站上下载，下载的过程一般需要 教师手动的查找自己需要的 Word 文档。教师下载并填写好文档以后再上传给系统或 者打印交给上级单位。 2. 由系统开发人员临时制作这样的数据录入页面，然后修改以前的页面连接，把新加的 页面加入原有的系统。 第一种方法虽然很直接，工作量也不大，但是给每个教师的数据录入带来了不方便， 也影响了学校数据收集的效率。第二种方法，非技术人员的工作量减少了，技术人员临时制 作静态数据录入页面亦非难事，但是这造成了发布系统的多变性，风格、形式难以统一，当 页面数量庞大，后期维护将相当困难。而且这样的开发方式，如果页面没有进行充分的调试 和测试，很容易出现错误乃至系统崩溃。 图 2.2 以当前高校的信息发布、收集模式为例，说明了这两种模式的工作流程及问题 所在： Web 下的可配置信息发布收集系统 10 图 2.2 现有信息发布、收集模式 2.2.2 信息发布的瓶颈 当前信息发布收集的几大突出问题： 1. 信息发布无法面向特定对象；检索不易；容易延误 每一种信息发布都有其特定的发布对象。例如，学生不应当有查看教师表格的权 限；院系教师不必关心教学秘书所需提交的信息。 现行的信息发布，无法针对特定的用户、角色或者用户群。换言之，要求收集的 数据通过网页的静态表格或表格下载的方式发布到网站，任何合法用户登陆进网站时 都可以浏览得到。这样，特定用户其实浏览到了许多与之无关的页面、数据，造成了 检索的不易甚至是误报、错报、重复填报。面向某个单位、部门或者是整个高校，各 类需要提交的表格、文件等不计其数，而面向该单位下的某个特定用户，很可能需要 填写、提交的表格、文件数量是有限的。现行的系统中，往往出现这样的情况：某个 用户登陆系统之后，在表格下载区上百个表格中，寻找不到自己应该填写的表格。造 成了信息提交的延误。 Web 下的可配置信息发布收集系统 11 2. 用户必须填写所有信息 每一份需要提交的表格、文件中需填写的字段一般非常之多。笔者进行本文系统 需求分析过程中，曾与某处负责数据收集的教师交谈，据他反应，在他们部门，用现 行的填表方式，一个工作人员一天之内平均只能填写 10 份表格文件。效率之低令人 惊异。而这样的情况绝非个例。笔者身为学生，平常也需要提交各种表格，发觉平常 众多表格虽然字段繁多，但各表格之间的许多字段均为重复字段，例如：姓名、性别、 年龄、院系、学号、籍贯等等。这些字段信息在校园信息化的中央数据库中都有保存， 现行的信息填报系统无法将数据库中的字段信息与表格字段内容事前关联，造成相同 信息的重复填写，降低了填报的效率，同时也增加了用户填写过程的出错风险。 3. 用户填写不规范，提交之后不合格信息多，审核困难 用户对表格、文件设计不甚了解，当他们面对一份空白的表格或者文件，而又没 有专门人员进行指导和说明，很容易误解表格信息，导致误填。这样，提交后的表格 需经过审核人员对填报信息逐个字段审核，一旦发现不合格信息，需要反馈给用户重 新填写，再次提交。如此往复，一直到合格。在本身填报效率就不是很高的填报系统 上，用这样的方式收集信息，让发布者和提交者都疲惫不堪，完全体会不到办公自动 化的优越性。 2.3 本文提出的解决方案 针对以上几大问题，本文提出了一个相应的解决方案，可以解决静态方式报送带来的 问题，同时具备更多的优点。 1. 建立一个基于 B/S 构架下的 Web 信息发布、收集系统。使得从信息发布方到需要提 交信息的用户，乃至信息统计部门，都在同一个系统平台上操作数据。达到数据录 入、收集、统计的统一性；同时把用户从海量的信息中解救出来，使之能方便快捷 地接触到属于自己的信息。信息提交方式由原来的下载表格自行填写等统一成登陆 网站提交，接口统一，界面友好，用户接受度高。 2. 本文系统下的信息发布页面，摒弃了以往手动制作静态页面的做法，而只需要信息 发布方按纸质表格、文件的格式，用一般的网页开发工具：FrontPage、Dreamwaver 等画出空白表格格式，转存成.XML 模板即可。系统会自动解析 XML 中存储的表格板 式信息，呈现于 Web 页面。无论何种排版、什么样的文件，经过本文系统解析之后， 都将动态加载到 Web 中，无需根据每种不同表格，开发多个页面。 3. 本文系统提供了可视化的配置页面。管理员在管理员界面中可以配置自己权限下的 所有空白表格模板。即在 Web 下直接为空白表格增添字段。可以根据表格需要，增 加标签、输入框、下拉框、复选框和单选按钮等。配置好的表格节点信息存储在相 应 XML 文件中，随时可以再次配置修改。 4. 用户录入页面动态加载。用户选取应填写的表格，系统解析相应 XML 文件中存储的 表格信息，动态加载完整的表格提交页面。 5. 表格的预填。上文提到，种类繁多的表格中，有许多信息是中央数据库中已经存在 的，并不需要用户多次重复填写。对于这些字段，本文系统支持管理员在配置页面 时绑定数据库中已有字段，当用户登陆到自己的提交页面，这些字段将根据该用户 的具体信息对表格进行预填，这将大大减少用户填写的时间，也减少了不必要的填 写错误。 Web 下的可配置信息发布收集系统 12 6. 本文系统中信息发布采取了“用户和角色”的概念。将特定的表格分配给特定角色 的用户或者用户群。比如，院系 A 的表格只分配给院系 A 的教师，这样，其他院系 教师登陆到同样系统，但无需浏览到院系 A 的表格文件信息。 2.3.1 新旧信息发布收集方案对比 表 2.1 显示了 3 种信息发布收集方案在性能和适用性上的对比： 表 2.1 信息发布收集方案对比表 解决方案解决方案维护难度维护难度可定制性可定制性使用简易度使用简易度功能性功能性 Word 等格式文 件提供下载 难以维护、统计不可定制使用麻烦无附加功能 临时制作静态 输入页面 难以维护，出错率高 不可动态自 动定制 较方便无附加功能 动态可配置系 统 页面动态加载，维护 相当便捷 可视化定制十分方便 在线修改、审 核功能 Web 下的可配置信息发布收集系统 13 第 3 章 系统所涉及的技术及其概述 3.1 面向对象的分析和设计 本系统采用 C作为开发语言，使用面向对象的分析和设计。在面向对象分析的过程中， 强调的是在问题领域内发现和描述对象或概念；在面向对象设计过程中，强调的是定义软件 对象和这些软件对象如何协作来满足需求。 在本系统的分析和设计中，我们强调各软件组件的职责问题，为不同的软件对象或组件 分配其应有的职责是关键也是最基本的工作。其中还应用一些成熟的模式进行分析和设计， 使系统各模块结构更清晰，工作更协调。 在开发过程中，我们使用 UML 语言进行面向对象的建模，用统一过程进行迭代开发。 3.2 分层架构 分层架构是当前比较流行的系统架构模式，本系统采用三层架构的模式，分别是表示层、 业务层、数据层。此模式概述了每一层的职责以及组成每一层的组件，如图 3.1 图 3.1 Three-Layered Services Application 图 3.1 显示的 Three-Layered Services Application 基本上是一个松散的三层体系结 构，三层的概要说明如下： Web 下的可配置信息发布收集系统 14 表示层：表示层提供应用程序的用户界面 (UI)。这通常包括 Windows 窗体（用于智能 客户端应用程序）和 ASP.NET 技术（用于基于浏览器的交互）的使用。 业务层：业务层实现应用程序的业务功能。业务层通常由使用一种或多种支持 .NET 的 编程语言实现的大量组件组成。 数据层：数据层提供对外部系统（如数据库）的访问。该层涉及到的主要 .NET 技术是 ADO.NET。但是，在这里也经常用到一些 .NET XML 功能。 3.3 XML 技术 可扩展标记语言（Extensible Markup Language，XML）是由万维网联盟（World Wide Web Consortium，W3C ）开发的，主要目的是为了克服 HTML 的缺点，XML 对于 HTML 来说， 特点是：没有预定义的标记；更严格的语法。XML 的应用主要分为文档应用和数据应用。在 文档应用上 XML 的主要优点在于它的重点是文档的结构，这使得它独立于传播媒介。在数据 应用方面，通过 XML 形成了一个完整的体系，为数据的分发带来了一种出版模式。用 XML 文 档可以来表示数据库结构，还可以表示某种文档的结构。 在本系统中，主要应用 XML 在数据应用方面的功能，一方面通过 XML 来存储和表示数据 录入页面的文档结构，用来存储其外观信息，另一方面通过 XML 来存储教师所提交的信息， 达到使用同使用数据库同样的效果。 3.4 ASP.NET 技术 ASP.NET 是 Microsoft .NET Framework 中一种用于生成 Web 应用程序和 XML Web services 的技术。ASP.NET 页在服务器上执行并生成发送到桌面或移动浏览器的标记（如 HTML、WML 或 XML） 。ASP.NET 页使用一种已编译的、由事件驱动的编程模型，这种模型可 以提高性能并支持将应用程序逻辑同用户界面相隔离。ASP.NET 页和使用 ASP.NET 创建的 XML Web services 文件包含用 Visual Basic .NET、C# .NET 或任何 .NET 兼容语言编写 的服务器端（而不是客户端）逻辑。Web 应用程序和 XML Web services 利用了公共语言运 行库的功能，例如类型安全、继承、语言互操作、版本控制和集成安全性等。 本文系统应用 ASP.NET 中可以在运行时动态创建服务器控件来达到产生动态数据录入页 面的需求。 Web 下的可配置信息发布收集系统 15 第 4 章 基于 Web 的以 XML 驱动的信息发布、收集系统构建 4.1 系统开发与运行环境 表 4.1 系统开发与运行环境表 4.2 系统需求分析 4.2.1 功能性需求 1. 具有用户登陆、权限控制的功能。 2. 具有数据输入页面模板上传的功能。 3. 具有对模板进行配置的图形化界面。 4. 具有对数据输入页面按用户和角色分配的功能。 5. 具有查询所收集的信息的功能。 6. 具有对数据输入有按照数据库原有信息进行预填写的功能。 7. 具有对输入数据按照页面格式进行报表预览的功能。 4.2.2 性能性需求 由于系统的侧重点是在完成功能性需求，对于系统的性能需求不做过多的考虑，主要 有以下两点： 1.系统吞吐量和响应时间。现有的系统吞吐量和响应时间主要取决于作为服务器的机器 的性能和网络的状况。 2.系统的安全性。结构上，后台系统采用的是与前台系统（即与用户交流的部分）完全 系统开发与运行环境 开发模型 B/S 服务器平台 IIS5.0 编程语言ASP.NET （C#） 编程工具 Microsoft Visual Studio.Net 操作系统 Windows 2000 Professional Web 下的可配置信息发布收集系统 16 独立的结构，降低了受到恶意用户攻击的可能性。另外，后台应用程序采取了使用用 户名登录的加密措施，以保证数据库操作的安全性。 4.3 业务流程分析 信息发布、收集系统的业务流程分析分为：页面配置流程分析、信息分配流程分析、 用户提交修改流程分析、查询修改流程分析。 4.3.1 页面配置流程分析 管理员登陆之后可对空白表格进行字段绑定、字段类型配置。具体流程如图 4.1 所示： 图 4.1 页面配置流程 4.3.2 信息分配流程分析 管理员可按用户姓名和按用户角色两种方式把信息录入页面权限分配给对应用户或者 用户群。 4.3.3 用户录入、修改流程分析 管理员登陆之后可对空白表格进行字段绑定、字段类型配置。具体流程如图 4.2 所示： Web 下的可配置信息发布收集系统 17 图 4.2 数据录入、修改流程 4.3.4 查询流程分析 查询模块系统管理员页面和普通页面部分都会出现。在用户查询页面中查询流程和用 户录入页面流程大致相同。在管理员查询页面中，有两个查询方式：按用户名和按表格模板。 管理员选择查询方式，可对查询结果进行预览和审核。 4.4 数据库设计 4.4.1 数据库设计概述 本系统并没有采用一般的数据库系统作为系统的数据驱动核心，而是采用 XML 文件作 为系统的数据驱动核心，这样做的原因有两点： 1. 关于数据输入页面配置的外观信息用 XML 文件来存储和表示可以利用面向对象思想， 把页面信息中需要地 html 代码直接在 XML 节点中体现。 2. 关于用户所输入的信息，可用一般数据库来存储，但考虑到后台数据库可以是各种类 型,比如 Oracle, SQL Server 等, 如果用 XML 文件作为中间层,将会很容易在多个数 据库之间做传输和同步,这样系统的可移植性将会增强。 4.4.2 XML 文件概要说明 表 4.2 XML 文件说明 文件名文件名说明说明 users.xml 存储用户信息的 xml 文件。 roles.xml 存储角色信息的 xml 文件。 页面外观模板.xml模板 xml 文件，该文件的名字是不定的，模板可以由用 户上传，该文件的节点结构是不变的。 RepCollection.xml 存储模板文件与数据输入页面名称对应关系的 xml 文件 模板对应数据存储表.xml数据存储文件，该文件与一个确定模板一一对应。文件 名可以由用户设定，文件节点结构不变。 Web 下的可配置信息发布收集系统 18 图 4.3 数据库文件关系示意图 4.4.3 页面外观配置相关的信息存储 关于数据输入页面外观配置信息一概存入模板文件中，该模板文件的结构为一个 Html 的表格，利用 Html 的表格的结构来达到页面外观的可配置。该 xml 文件的节点结构如图 4.4 所示： 图 4.4 模板文件节点示意图 节点说明如表 4.3： Web 下的可配置信息发布收集系统 19 表 4.3 模板文件节点说明 节点名称节点名称说明说明备注备注 table 模板文件根节点，表示一个表格 tr 表示表格中的一行 td 表示一行中一个单元格，每个单元格有不定数目的 control 节点 control 用来表示一个控件的控件节点根节点 type 表示该控件的类型，现阶段有如下类型：标签、文本 输入框、下拉框、多选框、单选框 cValue 表示控件名称 text 表示控件内容 width 表示控件宽度和高度部分使用 required 表示控件内容是否必填部分使用 regular 表示控件内容要规范的正则表达式部分使用 erroMessage 表示错误消息部分使用 style 表示控件风格，如文本框有单行多行部分使用 分控件类型说明各节点： 1. 标签控件（Label）： 表 4.4 Label 节点名称节点名称说明说明 type 节点内容为 label，指名该控件为标签控件 cValue 该控件名字，默认为 label text 标签控件内容，由用户配置时候输入 width 未使用 required 未使用 regular 未使用 erroMessage 未使用 style 表示标签控件内容字体大小，默认 13 2. 文本输入框控件（TextBox）： 表 4.5 TextBox 节点名称节点名称说明说明 type 节点内容为 textbox，指名该控件为文本输入框控件 cValue 该控件名字，默认为 textbox text 文本输入框控件内容，由用户配置时候输入，用户配置还可以配置 该内容为映射数据库中的某个字段，实现数据输入的预输入功能。 width 文本输入框控件的宽度和高度，宽度和高度之间用“|”分隔。 required 表示文本输入框是否为必填内容，用来规范数据输入页面数据录入。 Web 下的可配置信息发布收集系统 20 regular 规范数据录入页面中文本输入框的内容，可以选则“数字、 Email、邮编、电话号码”等等。 erroMessage 文本输入框如果输入错误，页面显示的错误信息，默认为“输入错 误” style 表示文本输入框控件为单行还是多行，默认为单行。 3. 下拉框（DropDownList）： 表 4.6 DropDownList 节点名称节点名称说明说明 type 节点内容为 dropdownlist，指名该控件为下拉框控件 cValue 该控件名字，默认为 dropdownlist text 下拉框控件内容，有用户配置时候输入，用户配置还可以配置该内 容为映射数据库中的某个字段，实现数据输入的预输入功能 width 下拉框控件的宽度。 required 未使用 regular 未使用 erroMessage 未使用 style 未使用 4. 多选框（CheckBox）： 表 4.7 CheckBox 节点名称节点名称说明说明 type 节点内容为 checkbox，指名该控件为多选框控件 cValue 该控件名字，默认为 checkbox text 多选框控件内容，有用户配置时候输入，用户配置还可以配置该内 容为映射数据库中的某个字段，实现数据输入的预输入功能 width 未使用 required 未使用 regular 未使用 erroMessage 未使用 style 表示多选框控件内容横向排列或者纵向排列，默认横向排列。 5. 单选框（RadioButton）： 表 4.8 RadioButton 节点名称节点名称说明说明 type 节点内容为 radiobutton，指名该控件为单选框控件 cValue 该控件名字，默认为 radiobutton text 单选框控件内容，有用户配置时候输入，用户配置还可以配置该内 容为映射数据库中的某个字段，实现数据输入的预输入功能 width 未使用 required 未使用 Web 下的可配置信息发布收集系统 21 regular 未使用 erroMessage 未使用 style 表示单选框控件内容横向排列或者纵向排列，默认横向排列。 4.4.4 用户数据相关的信息存储 本文系统采用 XML 存储用户提交的数据。一般而言，这部分信息可采用 Oracle、SQL Server 等数据库来存储。但考虑到本系统需要跟不同的数据库系统进行对接,将这部分数据 的存储也暂时使用 XML 文件进行保存。在数据层保留了与其他数据库的接口。系统一旦需要 与具体高校信息化平台整合，可以方便安全地同其他种类数据库做信息的传输和同步。这类 的表格在本文系统中有一下几种： 1. 报表信息表： 用户提交的表格信息需要存放到数据库中。这些信息存放在表 reportData.xml 中。 结构如图 4.5： 图 4.5 数据文件节点示意图 数据文件节点说明如表 4.9： 表 4.9 数据文件节点说明 节点名称节点名称说明说明 reportdata 表示一张表格对应的数据存储文件 report 表示一次提交的表格数据根节点，属性 id 唯一标识 item 表示一个控件名，属性 id 唯一标识 data 某个控件下存储的数据 time 该控件下数据最后一次修改时间 这样三层的节点，使得每次提交的信息都可以通过 report id 很方便地查询得到。甚 至是表中个别字段的信息，也都可以通过 item id 查询，便于修改。 2. 用户信息表 用户信息也需要存储在数据库中。因为前面所讲述的原因，本文系统将用户信息存放 在 user.xml 中，并且只是模拟高校信息化平台中的若干用户信息字段。今后在实际的高 校信息化平台中架设本文系统的时候，这些信息已经存在于中央数据库的人事数据库中， Web 下的可配置信息发布收集系统 22 无需另外建设新的数据库。 user.xml 表结构如图 4.6 所示： 图 4.6 user.xml 文件节点示意图 文件节点说明如表 4.10： 表 4.10 user.xml 文件节点说明 节点名称节点名称说明说明 userlist 表示一个用户基本资料数据存储文件，属性 id 唯一标识 user 表示一个用户对应数据根节点 name 表示一个用户名 password 表示该用户登陆密码 type 表示该用户类型 phone 表示该用户电话号码 address 表示该用户家庭住址 sex 表示该用户性别 dept 表示该用户所属院系 report 表示该用户所被分配的表格集合 item 表示该用户所被分配的一个表格 repName 表示该表格对应的数据存储文件名 repFile 表示该表格对应的模板文件名 3. 角色分配表 本文系统的表格、文件均以角色或用户的方式分配给特定用户，role.xml 文件就是 用来存放这些信息的。 xml 文件结构如图 4.7： Web 下的可配置信息发布收集系统 23 图 4.7 role.xml 文件节点示意图 文件节点说明如表 4.11： 表 4.11 role.xml 文件节点说明 节点名称节点名称说明说明 rolelist 表示角色分配表 role 表示一个角色，属性 id 唯一标识 userlist 表示属于该角色的用户列表 user 表示一个属于该角色的用户名 reportlist 表示该角色所被分配的表格集合 item 表示该角色所被分配的一个表格 repName 表示该表格对应的数据存储文件名 repFile 表示该表格对应的模板文件名 4. 模板关联表 一个模板文件对应有一个数据存储文件。repCollections.xml 文件中存放了他们之 间的对应关系。Xml 文件结构如图 4.8： 图 4.8 repCollections.xml 文件节点示意图 文件节点说明如表 4.12： 表 4.12 repCollections.xml 文件节点说明 节点名称节点名称说明说明 reportlist 表示表格、文件集合 Web 下的可配置信息发布收集系统 24 report 表示一个表格、文件 name 表示该表格、文件对应的数据存储文件名 file 表示该表格、文件对应的模板文件名 4.5 界面设计 4.5.1 系统界面总体设计 系统页面色调采用黑白蓝的色系，配合一定的图标，以简洁大方为总体风格。系统页面 由三大块组成：登陆页面、用户功能页面、控件设置页面，后面将进行分别说明。 4.5.2 第三方组件 本系统在界面方面用到了四个第三方组件，分别是： 1. obout 公司的 Splitter，公司主页：。 2. obout 公司的 Slide Menu。 3. obout 公司的 Easy Menu。 4. MetaBuilder 公司的 DualList，公司主页：。 4.5.3 登陆页面 页面说明：页面说明： 1. 页头：窄框色 值#555555； 字体色 白色 2. 页体：主色 #6B89AF 3.页脚：窄框色 值#555555 图 4.9 登陆页面外观层 Web 下的可配置信息发布收集系统 25 4.5.4 用户功能界面 页面说明：页面说明： 1. 页头：显示当 前登陆者姓名。 2. 功能下拉菜单： 显示当前用户 能使用的功能。 3. 具体操作页面。 4.页脚：显示版 本信息。 图 4.10 用户功能界面外观层 4.5.5 控件定制页面 页面说明：页面说明： 不同的控件 有不同页面，右 图示例的是文本 输入框控件的定 制页面。 页面由页面 标题和定制内容 组成。 图 4.11 控件定制页面外观层 4.6 模块实现 本文系统按用户角色可分为两个模式：管理员模式和普通用户模式。 Web 下的可配置信息发布收集系统 26 管理员模式下，用户可以对所有报表进行字段配置，角色分配，还可以对报表进行查询、 审核甚至修改。普通用户模式下，用户能看到属于自己的所有报表，填写、提交这些报表， 也可以对自己已经提交的报表进行查询。 因为两种模式下的某些功能有重复的地方，所以本系统按照功能划分，又可分为 6 个 模块：登陆模块、分配模块、配置模块、录入模块，查询模块和修改模块。本文作者在这个 系统中，负责录入模块，查询模块和修改模块的实现。下面将从这个角度详细阐述作者是如 何实现这 3 个模块。 4.6.1 三个模块涉及的类及其类图概述 1. BRep 类(控制层） 图 4.12 BRep 类图 BRep 类实际起了一个映射 Template 类和 ReportData 类的作用。BRep 有两个属性： Name 和 File。在本文系统种，一个 template 实例对应一个存放表格模板页面信息的 template.xml 文件。而一个 reportData 实例则对应一个存放某个具体表格模板数据信息 的 reportData.xml 文件。这两者的关系是一一对应的。如何把他们关联起来呢？作者新 建了一个 RepCollection.xml 文件，专门存储他们之间的一一对应关系，并用 BRep 类来 实现。BRep 的 File 属性代表了 template.xml 文件名，Name 属性中存放的则是这个 template.xml 文件所唯一确定的 reportData.xml 文件名。这两个文件名都可以让用户自 行设置，我们要做的仅仅是把他们关联并确定下来。 2. Item 简单类图(控制层) 图 4.13 Item 类图 Item 类、Report 类和 ReportData 类是本文作者实现录入、查询、修改模块的重要 的类。他们共同实现了用户提交的数据如何从动态页面中取得，并根据不同页面的数据 Web 下的可配置信息发布收集系统 27 个数，往 xml 文件中动态添加节点，存储数据。也实现了根据用户要求的页面，把节点 数据提取出来，再关联到动态页面的相应位置。 正是因为所有数据和页面控件全部必须动态加载，所以页面无法按照普通的方式制 作：即先在页面中拖放控件，之后绑定数据库字段。为了达到动态加载的目的，我们把 页面中的控件信息（包括控件类型和控件位置、控件属性、验证规则）存储在”模板. xml”文件中。把控件对应的数据信息（即用户填写到控件中的数据）也存储在相应的” 数据.xml”文件中。Item 类就是用来存储单个控件的数据信息的。他有一个 itemID 属 性，唯一标识了这个控件名。并且我们把控件名的形式规定为： reportID_trN_tdM_cJ 其中 reportiID 是该控件的数据信息所属的 reportID，trN 代表控件位于表格的第 N 行，tdM 表示控件位于表格的第 M 列，这就确定了控件在页面表格中的具体单元格位 置，cJ 则是表示这个数据是属于该单元格下第 J 个控件的。例如有一个 itemID 的属性 为：“teacher001_10_tr3_td2_c1”,它代表的是该控件的数据属于 reportID 为 “teacher001_10”的数据节点，该控件在页面中处于第 3 行第 2 列的第 1 个控件位置。 这样，从数据和页面位置两个方面来标识这个控件。 通过这个 itemID，能立刻找到这个控件数据所对应地控件在页面中的具体位置，就 能把数据和控件之间关联起来，方便地进行数据存储和提取。 3. Report 简单类图(控制层) 图 4.14 Report 类图 同 Item 的任务相近，report 类也是用来实现数据保存和提取的。它保存了用户对 某个模板一次提交的所有信息。即某个用户在某个时刻对某张表格进行填写和提交，这 所有的信息的操作都由一个 Report 实例进行。一个 Report 有唯一的 reportID 标识， 它的结构是： userID_N 其中 userID 是当前登入系统的填表用户自己的 userID，N 代表所填表格被提交的次 数。这样的 ID 结构保证了用户每次提交都是产生一个不重复的 reportID，同样是为了 根据 reportID 保存、修改和查询该次的提交数据。再以本文前面提到的例子， reportID 为“teacher001_10”表示这个数据是用户 id 为 teacher001 的用户提交的。 并且他那一次提交数据之前，已经有 9 人/次对该表格进行过提交。 一个 report 实例中包含有若干 item 实例，在现实中的意义就是：每张表格中有若 干个字段。 Web 下的可配置信息发布收集系统 28 4. ReportData 简单类图(控制层) 图 4.15 ReportData 类图 不言而喻，reportData 类用来存储所有用户对某一张表格所提交的信息。用户提交 一次该表格的