GuiXML解释引擎的JavaScript的设计与实现
开题报告
班级（学号）0413307 姓名 田野
指导教师 张鹏
一、综述
软件构件图元编辑标准，以下简称基于XML的软件构件图元编辑规范（GUI XML），是一种用于描述图形化用户界面构造过程所需应用逻辑的语言，其描述的界面具有设备独立性模式。这里所说的"设备"，意味着个人计算机、多种信息应用设备（例如手持式电脑、桌面电话、蜂窝式电话和PCS电话），以及其他人类可以与之交互的设备。GUI XML是一种说明性的、符合XML规范的语言。 为了开发一个用户界面，设计者需要编写一个GUI XML文档，其中包含了适用于最终使用此用户界面的设备的表示风格信息。之后GUI XML将被使用特定的编程语言工具包完成用户界面的构造（例如JFC、SWT等），或者自动映射为目标设备所使用的语言（例如HTML、WML）。 GUI XML的设计目标如下：
·使得设计者不需要学习针对特定设备的语言和API就可以设计出符合设备要求的UI；
·缩短针对一系列不同设计开发用户界面的时间；
·提供了将UI代码与应用逻辑代码相分离的特性；
·使得非程序员能够设计UI；
·简化国际化和本地化的工作量；
·实现了通过网络将UI下载到客户端的高效；
·有助于强化安全性；
·实现了对支撑UI技术的扩展。
目前，项目组已经完成了在 Java Desktop 上SWT与Swing对GUIXML的支持，可以通过自建立 GUIXML 文档生成图形化的 Java Desktop Applications。本课题的研究意义在于，将 GUIXML 映射为浏览器可以识别的语言（ HTML ），并在其开发过程中，确定 GUIXML 通用性的最小支持范围，从而构建 GUIXML 的 Lite 版本。
二、研究内容（宋体加黑，小四号）
研究方向：
Web Based Rich Client
研究内容：
使用JavaScript制作GUIXML的浏览器可识别的解释引擎。
系统功能：
通过浏览器加载JS解释引擎以及相应的GUIXML文件，并使用这个引擎将这个XML文件解释或翻译为浏览器可识别的语言或者代码，从而生成网页UI。
三、实现方法及预期目标（宋体加黑，小四号）
初步设计方案：
初步方案包括引擎加载部分的设计、内部架构的分析、支持组件等三个部分。
加载部分的初步设计方案：
通过一个Function来激活JS engine 工作，这个Function可以被加载到<body>标签中的onload中进行调用或者通过其他的一些链接，比如<a>标签，href=”#” onlick的时候，调用这个Function，从而激活JS engine的解析。（图3.1 解析引擎加载流程）
图3.1 解析引擎加载流程
同时，还可以考虑加入引擎配置文件，在加载引擎之后，引擎自动开始加载其配置文件，读取相应的配置然后开始对xml文件进行解析。（图3.2加入配置文件的解析引擎加载流程）
图3.2 加入配置文件的解析引擎加载流程
内部构架初步方案：
引擎解释过程的分析：
思路：使用xmldom 进行解析，然后将解析到的attribute和value存在表中。
备注：这些表是引擎中生成用的表，而不是引擎中自带的一个分析表。
component 表。
这张表里面存放的是所有 component 的名称以及他们的类型，如示例:表3.1。
表3.1 Component表示例
| Component名称 | 类型 |
| Button1 | Button |
| Text1 | Textfield |
| …… | …… |
引擎对输入数据的要求：
Component名称是必不可少的，因为需要通过名称去关联属性表以及其他的一些表，那么这里就有一个问题，就是名称是不可以重复的。这个就需要一个良好的IDE工具来对这个问题进行解释分析，或者抛出一个异常。最后生成的这样表必须是一个干净的表。也就是说，初期的引擎对输入的数据的要求比较严格，不能包含一些带有二义性问题的数据。
那么，类型的话就是包括lv1类型（对应底层基本组件）以及lv2（对应第二层基本组件或更多同层组件）类型或者higher的类型。通过分析类型，来对其的 attribute 进行分析。
attribute 表。
Attribute 表中存储的是 component 的属性。
比如说，button的value，或者textfield有没有边框等等这类的属性。如示例:表3.2。
表3.2 Attribute表示例
| Component名称 | Attribute | Value |
| Button1 | Value | 确定 |
| Text1 | Text-overflow | Clip |
| … | … | … |
解释的方法，就是从 component 的名称中查询component表得到component的类型，然后查询attribute表中的attribute，查看是否支持这个属性，如果不支持就忽略掉，然后如果支持的话，把attribute和value写入到style中去就可以了。
其实，就是一个字符串的拼接。比较的麻烦，这个工作量可能有点大，最后做到全部拼接就可以了。最后一个就是事件相关的一个 event 表。根据现在的项目进度安排暂时不考虑。
探讨：对component 表的更新。
假定，每一个guixml文档都是一个frame。每一个frame都拥有他自己本身的一个name。这个应该是可以保证的。然后，在读取多文档的时候，engine需要对frame的域进行保存，比如，需要知道component被包含在哪一个容器中。这样的话，就需要对现有的component表进行更新，更新结构示例如表3.3：
表3.3 更新的Component表示例
| Component名称 | 类型 | 从属 |
| Button1 | Button | Frame1 |
| Text1 | Textfield | Frame1 |
| 。。。 | 。。。 | 。。。 |
| Frame1 | Frame | 本身或者其他frame |
其实这里还可以考虑更适合的一种方法，就是采用树形结构来完成表同样的目的。将这些组件按照从属关系放入树形结构中去，也就是，在表3.3中从属一栏中的组件相当于是父容器，Component名称也就是其子容器或者子组件，包含于这个父容器之中。
也就是说，将表3.3 改为一下图：
Frame1
|-------Button1
|-------Text1
|-------。。。。。。
其他容器
|-------容器组件1
|-------组件1
|-------组件2
|-------组件2
。。。。。。。。。。
图3.3 Frame1的树形图
解析实现的探讨：在解析上，引擎同样需要对这棵树进行解析的，不过考虑这棵树应该还是在内存中存储，应该同样用一个2维数组来对其实现，那么，这个2维表可能还是如同表3.3一样。
引擎的分析表
引擎的分析表同样分成两种，一种是Component表，另外一个是Attribute表。
Component表
一开始想的有些复杂，其实这样表可以很容易。因为仅仅需要解释引擎判断这个组件是否被引擎支持就可以，而不必过多的分析组件的构成，因为构成不是这一步要做的事情，而是当遇到复合组件的时候才需要考虑到的问题。示例如表3.4。
表3.4 引擎支持的表的示例
| 类型 |
| Button |
| Frame |
| Panel |
| 。。。 |
Attribute表
Attribute表存在2种，为的是更好的继承性。
每一个component都有自己的attributes，那么很多component的attributes也是有交集的。比如说，button中有value，textfield中也有value，只不过在解析的时候，button被解析为一个复杂容器，textfield被解析为一个单一容器。Value也被放置在了不同的地方，但是他们都是有相同的attribute。这样的话，attribute表就不是那么简单的去做了。
备注：这里的attribute表是css的attributes。
首先，抽象出所有的组件的属性，将相同的attribute放置在一个table中。
basic_attribute表（表3.5）
表3.5 Basic_attribute表
| 属性 |
| Text-align |
| position |
| font |
| 。。。。 |
这样表里面包含了所有组件都共有的属性，这样在解释的时候，引擎会从这些属性中先判断出组件的一些基本信息，把它们存储到生成的Component表以及Attribute表中。
然后，根据每个component的不同，找到他们不同的attribute：比如说是frame的属性，如表3.6：
表3.6 Frame的属性表示例
| Frame |
| z-index |
| Top |
| … |
这些属性对于其他比如Button组件来说是没有用处的，因为在这里，button仅仅需要的是一个绝对的相对container的定位。不尝试能够实现drag and drop 这个功能。那么，在查表的时候，首先查得是这个basic的表，然后再根据生成的Component表的类型来查看相应type的表。这样做的好处就是在于，如果需要更改、更新或者添加新的属性元素的时候，仅仅需要的是CRUD，而不是需要再次update所有的表，从而避免了产生大量的资源waste以及冗余。
这两个表的关联就是通过解析器来完成的，因此在解析的过程中会在意到一定的顺序问题，这个也是需要考虑的，如果暂时不考虑一些其他的性能问题。
其实通过这两张表的分析，我们可以得出在引擎加载流程中配置文件的内容了。
一份的配置文件是存储所有组件的信息，比如支持哪些组件，以及组件的基本描述信息，比如组件的静态CSS属性等等。另一份的配置文件是存储所有的属性信息：一个是存储通用的支持属性，也就是Basic表，另外一些表就是相应类型的配置文件了。命名以及管理方法以参考“JAVA年会论文-利用Java实现简单XML数据库方案”中的数据库、数据表管理中的设计方案，这里就不多陈述。
支持组件初步方案：
经过初步考虑，理论上可以被支持的基本组件如表3.7基本支持组件表所示。
表3.7 基本支持组件表
| 组件名称 | 备注 |
| 底层组件（基本） | |
| BUTTON | BUTTON解释为两种，一种是无逻辑的<BUTTON>，一种是含有处理逻辑的<INPUT>。 |
| TEXTFIELD | 解释为HTML的单行文本框<INPUT>标签 |
| LABEL | 解释为form的<LABEL>标签 |
| PASSWORDFIELD | 解释为密码输入框<INPUT type=password>标签 |
| TEXTAREA | 解释为多行文本框<TEXTAREA>标签 |
| COMBOBOX | 解释为下拉菜单,<SELECT><OPTION>结构标签 |
| LIST | 解释为列表, <SELECT><OPTION>结构标签 |
| RADIOBUTTON | 解释为单选按钮，<INPUT type=radio>标签 |
| CHECKBOX | 解释为复选按钮，<INPUT type=checkbox>标签 |
| LINK | 解释为链接，<A>标签，不过为了支持GUIXML规范，可能会被舍弃 |
| FRAME | 解释为层标签<DIV>，考虑使用复合方式实现 |
| DIALOG | 解释为层标签<DIV>, 考虑使用复合方式实现 |
| PANEL | 解释为层标签<DIV> |
| IMAGE | 解释为图像标签<IMG> |
| 第二层组件（基本） | |
| TABLE | 解释为<TABLE><TR>[<TH>]<TD>结构标签，内容标签可能与底层结合 |
| TREE | 考虑解释为<DIV>标签组。有待讨论出方案 |
| TAB | 解释为<UL><IL><DIV>的HTML结构标签，<DIV>可以相当于Panel等 |
在这些组件中处理比较困难的是Tree组件以及Table组件，Table组件的困难在于，复杂的Table组件本身是一个容器，一个容器相当于多个容器，每一个cell都可以再包含组件，而这些组件还可以是容器。另外，Table容易出现一些错误，比如如果用户在写GUIXML文档的时候出现了多列的现象等等。Tree本身就是一个很复杂的容器。因为Tree包含了一种更复杂的结构，如何去解释这个结构是下面工作的重点以及难点之一。
开发、运行、调试环境：
操作系统：
首选：windows
原因：在windows下可以很简单的开发JS项目，并且可以在firefox以及IE中运行。
其次：solaris
原因：系统环境十分稳定。但缺点是之后firefox而没有IE，这样在IE8B1以下的版本中将可能出现一定的问题。故第二考虑使用solaris操作系统。
开发工具：
首选：SciTE
原因：SciTE可以对很多语言支持很好，具备标准的高亮显示，虽然他本身不具备调试功能，但是开发起来上手很容易，而且占用的系统资源极少。
其次：Netbeans
原因：极其强大的一款IDE，但是太强大了导致在windows环境下的效率不是太好。在solaris下的表现十分不错，但是solaris本身不可能支持IE，因此Netbeans作为候选。
调试、运行工具：
首选：IE8B1 emulate 7
原因：IE中自带有一款叫做webdev的toolkit，可以很容易的对JS进行语法分析，在IE8中同样有这类工具，虽然IE现在也不能很准确的报告错误的原因，但是在解析xml文件的时候因为采用了xmldom这个包，所以这就是首选IE的原因，同时也是首选windows的原因。
其次：Firefox
原因：firefox同样有很强大的debug工具，但是其一是不熟悉，其二是对于xml的解析，firefox支持的表现没有IE的好、方便。因此firefox作为备选。
四、对进度的具体安排（宋体加黑，小四号）
第一周～第四周： Feb. 25 - Mar. 21
完成任务书以及开题报告，确定解释引擎的实现方案
第五周～第九周： Mar. 25 – Apr. 25
基本实现解释引擎
第十周～第十一周： Apr. 28 – May. 09
完成论文初稿，完成解释引擎
第十二周～第十四周：May. 12 – May. 30
调试编码、修改论文
第十五周～第十六周：Jun. 01 - Jun. 13
答辩
五、参考文献（宋体加黑，小四号）
1、 清华大学 知识工程实验室编写， 软件构件图元编辑规范070621_征求意见稿，2007
2、 苏昱，样式表中文手册，2002
指导教师：（签署意见并签字） 年 月 日
督导教师：（签署意见并签字） 年 月 日
领导小组审查意见：
审查人签字： 年 月 日
1580
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
