本文共 5997 字,大约阅读时间需要 19 分钟。
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
指导教师:(签署意见并签字) 年 月 日
督导教师:(签署意见并签字) 年 月 日
领导小组审查意见:
审查人签字: 年 月 日
转载地址:http://eenpi.baihongyu.com/