楼主

理解SVG和XForms 可伸缩向量图形（Scalable Vector Graphics, SVG）和 XForms 是两种正在蓬勃发展的技术，它们面对的可能是电子文档出版中不同方面的问题。本文讲述了这两种技术的概要知识，并强调了这两者之间潜在的协作能力。 当我撰写本文时，有两种技术在刚刚发布或马上要发布的时候，就获得了令人难以置信的发展动力，在与各自相关的应用领域内掀起了小小的革命。 XForms 是人们期待已久的替代 HTML 表单的技术。它超越了对 XML 的简单重复，提供了一种 XML 编辑方案和经过抽象的用户界面层。与此同时， 可伸缩向量图形（Scalabel Vector Graphics, SVG）随着它加速进行的第二次小版本升级，戏剧性地扩展了应用的场合，适应性与可扩展性也比以往更高了。本次系列文章介绍了研究这两种技术的全新视角，并展示出将两者集成起来的方法。本文首先对 XForms 和 SVG 进行分析，并研究它们之间可能的相关性。 XForms XForms 是 HTML 表单的继任者，但是在开发基于表单的交互式应用中，HTML 表单的重要性不应该被忽视。 HTML 表单简史 我假设您作为一名 developerWorks XML 专区的读者，可能已经具有了 HTML（以及后来的 XHTML）及其表单功能的相关应用知识。HTML 表单最早实现了客户机和服务器之间的交互，这比静态文档请求更进了一步。HTML 表单是一种非常实际的方法。它通过各种不同的预先设置好的小控件（widget），如 简单的输入字段、文本框、单选按钮、组合框、选择列表等等，给开发 Web 内容的人员提供与用户交换文本数据的手段。毫不夸张地说，Web 能发展到今天这个状态，HTML 表单是起了重要作用的。不过我们还是要关注一下这项技术的真正意义。Web 并不仅仅是一种不可思议的催生新的发展趋势和全新经济模式等等的通信手段。事实上，Web 开发本身并不像听上去那么美好。每一个开发人员，只要曾经用基于表单的交互技术开发过哪怕是相当简单的 Web 应用程序，就能给您列出一大串让人心烦的问题。毫无疑问，这其中就包括 XForms 致力于解决的问题，比如验证，还有对用户界面控件输入值的限制等等。 在 HTML 时代，验证通常是很头疼的问题，开发人员解决这一问题的方法一般有三种。第一种，也是最直接的一种方法是，让服务器负责验证，一般是通过 Perl 这样的脚本语言实现的。编写这样的程序是异常乏味的工作，这种解决方案本身也很糟糕，因为每当在表单验证过程中遇到错误，就必须传回一个新文档，稍后再重新处理一次。第二种方法是在客户端验证，这牵扯到在完全与所用平台相关的对象模型上使用基于 Java Script 的脚本技术。第三种方法是第一、二两种方法的结合。不管您使用哪种方法，所需的工作依旧让人望而生畏，得到的结果也永远无法令人满意。 在用户界面方面，情况也不是很好。我在 上面列出的所有 UI 小控件一开始都还不错，但是很快问题就出现了。UI 控件的范围相当小，如果要提供更丰富的输入机制，如用于选择离开日期的日历，那么人们就必须采用智能化的客户端脚本和可怕的 DHTML 方法。这些技术对于兼容性而言都是可怕的负担。每一种表单控件的外观和行为都与特定的平台紧密相关。尽管这样的方法可以与用户的环境很好地集成，但是它限制了创建完整的定制控件的可能性，也无法为了实现更广泛的用途而对图形界面进行简单的修改，甚至不能保证多种平台上都具有一致的外观。 除了验证和用户界面控件这两个重大问题之外，设备依赖性、可访问性、缺乏与 XML 集成的手段等问题也同样值得关注，因此我们必须开始研究新的表单解决方案。当 W3C 开始开发下一代 Web 表单时，所有这些问题都被考虑进去了。 用 XML 方式实现的表单 近来很多 Web 应用程序都开始围绕 XML 做文章。随着这样的应用程序越来越多，XML 的功能已经体现到客户机上（比如使用 XHTML）。XForms 与 XML 平台紧密连接在一起，因此能与 XML 的处理流程完美结合。XForms 将表单的模型和表现完全分离，从而引入了一种全新的表单表示方法。 表单的 模型基本上是一种结构化的占位机制，用户可以通过适当的人机界面向其中输入数据。在 XForms 中，内容开发人员用 XML 定义这个模型，即采用最能满足需要的 XML 定制文法，根据特定的目标来建立模型的结构。一旦定义好模型之后，剩下的工作就只是定义哪些部分要通过用户界面暴露出来了。 用 XForms 定义用户界面的方法相当抽象，您也永远不会直接规定需要的 UI 看起来是什么样子。内容开发人员通过内置的 XForms 元素构建用户界面。从一种比较高的层面上来说，XForms 元素定义用户如何输入或选择模型中的某个特定元素（通过 XPath 表达式指定）。要是用没那么抽象的方式来表示最后一句话，在 HTML 中您说“在这儿画一个文本输入控件，让用户输入日期字符串”，而在 XForms 中，您说“给用户一个合适的控件，以便选择适合我的模型的值。” 这种方法是不错，但它到底是怎么解决前面那些问题的呢？XML 模型出色的地方在于，您可以（通过内置的 W3C XML Schema 数据类型或者XForms 自己的类型）真正将某一种数据类型绑定到模型中的任意元素上。首先，当用户输入或者通过控件选择某个值的时候，对这个值的验证工作可以通过 XForms 结合指定的数据类型自动完成。其次，由于您的模型元素具有数据类型，当您通过用户界面元素引用它的时候，您可以肯定，用户能获得一种适当的数据选择方式。在前面我们提到 XForms 中您可以说“给用户一个适合的控件，以便选择适合我的模型的值。”，因此，如果您想要提供的是日期类型的值，那么 XForms 就有可能识别出这些提示，为您显示一个日历控件来输入日期。 不管您是否相信上面的话，我这里也只是刚刚涉及 XForms 的皮毛而已，有关这方面的更多资料，请您参阅 参考资料。前面我提到过 HTML 表单的一个缺点，就是它缺乏对样式的支持。在 XForms 中，没有哪个用户界面元素具有多种外观，因为这些元素仅仅定义了交互中的约束条件（如可以选择的条目数）。数据类型是提示 XForms 将适当的输入控件表现给用户。您可以用 SVG 来实现 XForms的表现和交互层。下面看看 SVG 最近都取得了哪些进展，这些进展又是如何帮助我们实现上面的设想的。    收藏   分享   顶(0)    关闭广告显示

----------------------------------------------
事业是国家的，荣誉是单位的，成绩是领导的，工资是老婆的，财产是孩子的，错误是自己的。

	第2楼

可伸缩向量图形 XForms 和 SVG 的新特性之间具有潜在的协作能力，很多设想都可以因此而实现。 早期的 SVG 1.0 2001 年 9 月，SVG 1.0 成为一种推荐标准，从那个时候起，这种技术逐渐在相当多不同业务领域内得到应用。其中值得注意的应用范围包括地图与图形。最近，SVG 借助开放源代码项目在其自身之上进行了越来越多的面向应用程序的开发，这些项目的目标是提供可重用的、基于 SVG 的用户界面控件库。在这些项目中，交互式 SVG 的基础就是脚本语言（一般是 ECMAScript）和 DOM（包括 SVG 专用的扩展）。 虽然这些项目的基础都是相同的，但是库的架构却在朝不同的方向发展。构造这样的架构有一种非常直接的方法，即在库中提供面向对象的 ECMAScript API。这样，如果我想创建 SVG 的组合框，我就可以提供一个 SVGComboBox 类。用户可以创建这个类的实例，调用若干方法填充参数值，并发出绘制命令 —— 这种方式与传统框架中的普通 UI 工具箱非常类似，比如像 Swing、WinForms、Aqua 等等。虽然这些库事实上是在 SVG 之上建立起来的，提供 API 只是为了对库中的 DOM 脚本机制进行抽象，但是几乎不存在与 SVG 语言本身集成起来的情况。此外，使用每一种控件的定制 API 都需要经历一个学习过程，而且，我们没有利用 XML 内在的优点，如声明或语义等等。 可以用一种聪明些的方法来提供可重用的库，即让一些 XML 作为公共的 API。回到我刚才提到的组合框的例子，我可以在自己的名称空间中给用户提供一个 XML 元素，比如 <ui:comboBox> 。库中有一部分程序在加载的时候对整个文档进行解析，检查什么地方出现了 <ui:comboBox> ，然后构造出 SVGComboBox 对象。 <ui:comboBox> 元素基本上是作为一种速记的形式，用来调用 SVGComboBox 实例中所有必要的方法。由于我定制的元素是 DOM 的一部分，所以在用户通过 DOM API 访问我的定制控件或更改属性值（如 x 坐标位置，或控件内容）的时候，我还是可以使用转换事件。随着时间的流逝，很多开发人员都认为这种方法是更加适合的。他们相信，以 XML 为中心的方法更能适应于 SVG 环境。 然而人们已经证实，这种方法并不像原先想像的那样是最佳的方法。渲染的工作依旧在文档树中进行，人们已经证明这种做法在一些情况下会使系统崩溃。将所有的东西放在同一棵树中也是有风险的。最大的风险是自定义信息与原始结构混合。如果不同的扩展信息对文档树中的内容有所假设的话，上面的做法会导致它们之间不兼容。 一些 SVG 开发人员一直在讨论在 SVG 之上构建扩展机制的方法。这些讨论为 W3C SVG Working Group 提供了必要的信息，他们可以在规范中解决这些问题。在 SVG 1.2 中，我们发现了解决方案的第一个征兆，其中出现一种称为 RCC 的新特性。 揭开面纱：RCC 与 SVG 1.2 Rendering Custom Content (RCC)是在 SVG 环境中使用定制 XML 文法的最新基础框架。RCC 框架在 SVG 实现技术和概念之上提供了相当轻量级的一层。 RCC 给开发人员带来的主要快乐就是它将 SVG 1.0 以前隐藏得很好的一个概念暴露了出来，这个概念叫做 shadow tree（影像树）。影像树在 SVG 1.0 中用来扩展 <use>、<pattern> 以及 <marker> 这几个元素的 SVG 表现。直到现在为止，SVG 实现中依然包含了对影像树的操纵，RCC 允许外来文法中的任何元素都可以拥有公共的影像树，这样就将这种机制暴露出来了。SVG 1.2 为访问影像树提供了新的 DOM API；您可以通过常规的 DOM API，像操纵常规文档树一样操纵影像树。假设您生成的全部图形及附加的事件监听器都存在于一个自包含的树中，另外的组件很难触碰到。即便您真的想这样做，也要完全了解在这棵树之内做的任何工作都可能是破坏性的。有了影像树之后，文档树中剩下的唯一一样东西就是您的定制元素，除此以外别无他物。 您的目标是用 DOM 脚本控制定制元素，以及用通用的方式将定制元素集成到文档树当中。RCC 只是问题的一方面，如果您想让元素像其他任何 SVG 元素一样，那么事件方面也需要同样地处理。SVG 1.2 中有另外两个与 RCC 有关的新标准： DOM Level 3 Events和 XML Events（参阅 参考资料）。有了 DOM Level 3 Events，您就可以为定制类型创建专用事件。这样，当用户通过这个元素的图形外观（位于该元素的影像树中）选择新值时， <ui:comboBox> 就能够发出一个 select 事件。 能够发出定制事件当然很好，但是还需要能够 监听 这些事件。为此，可以使用原来 DOM Level 2 例程中的 EventTarget::addEventListener() 方法。然而，这种方法意味着需要一个编程环境，而我们通常期望能用描述性的方法在给定元素中实现对事件的监听。有了 XML Events，您就可以通过标准的声明语法来监听任意的事件，内置事件或自定义事件都可以。您不再需要那些基于属性的事件监听器（如 onmouseover ），也不需要朋友们的帮忙。同时，在事件方面，RCC 也为 SVG 带来了两个新的内置事件，它们与用 RCC 定义的外来元素的绑定机制有关。在本系列的下一篇文章中您将会看到，这两个事件，以及整个 RCC 框架，都是非常优秀的东西，它们使得 SVG 开发人员能提供与常规 SVG 元素类似的定制元素，从而为把 SVG 作为所有 XML 应用程序的全新编程平台铺平了道路。 结束语 XForms 是高度抽象的，基于 XML 的解决方案，对 HTML 表单构成了挑战。它实现了数据与表现的完全分离。同时，SVG 1.2 通过影像树和直接的事件集成机制，提供了更具扩展性的平台，并将这些封装在 RCC 框架中。了解这些情况之后，就应该开始用 RCC 提供的简洁方式构建定制 UI，然后在 XForms 环境中重用这些组件，从而提供一种丰富的用户体验。本次系列的下篇文章将着重介绍如何创建基于 RCC 的 SVG 组件，稍后，我们再深入探讨与 XForms 的集成。

----------------------------------------------
事业是国家的，荣誉是单位的，成绩是领导的，工资是老婆的，财产是孩子的，错误是自己的。