|
XML和现代CGI应用程序广告 XML和现代CGI应用程序
CGI::XMLApplication提供了一个基于XML、可以作为传统CGI脚本的模块。典型的CGI::XMLApplication脚本包括三部分:一个很小的提供对该应用程序访问支持的可执行脚本、实现各种管理者方法的逻辑模块、根据应用状态可能有一个或多个XSLT样式表,XSLT样式表能够将模块返回的结果转化成浏览器可以向用户显示的格式。 下面我们通过例子来简要地介绍CGI::XMLApplication的应用。 例1:CGI XSLT网关
为了重点说明这种分离,我们的第一个例子不是传统意义上的Web应用,而是一个通用的XSLT网关,它可以添加到服务器的cgi-bin中,将整个XML内容的目录树转化为符合请求的浏览器的格式,而这一切对于用户、样式表和文档的作者而言也都是透明的。 第一步是建立连接客户端的请求和应用的CGI脚本。我们希望XML文档能够方便地通过URL浏览,并使创建这些文档间的超链接非常直观。因此,我们将创建一个没有扩展名的CGI脚本,以便将它作为URL路径中的一个节点,节点右边的所有内容将在包含XML内容的虚拟文档环境中进行解释。在这种情况下,我们将CGI称作是样式表选择者。 use strict; 在加载合适的模块和设置一些在整个脚本范围内有效的变量后,我们开始向被传递给处理该应用逻辑的类的%context中添加一些域。在这个应用软件中,我们只传输要求的指向脚本文件路径右边的URL(REQUEST条目)和包含有存储在查询参数style中的数据的STYLE关健字。 $context{REQUEST} = $q->url(-path =>
1); 最后,我们创建了XSLGateway逻辑类的一个实例,并通过调用其run方法处理请求,将%context作为唯一的参数。 my $app = XSLGateway->new(); CGI脚本就完成了。下面我们创建完成大部分工作的XSLGateway模块: package XSLGateway; use strict; @ISA = qw(CGI::XMLApplication); 象我在简介中提到的那样,CGI::XMLApplication通过事件调用起作用:应用程序类中一个给定的方法的执行依赖于一个指定域的输入(一般情况下是用来提交表格的按钮的名字。),必须执行二种调用方法:selectStylesheet和requestDOM方法。 selectStylesheet返回有关的XSLT样式表的全文件系统路径。为了简单起见,我们假定样式表将保存在一个单一的目录中。我们可以通过$context->{STYLE}域提供其他的样式表,从而增加系统的灵活性。 sub selectStylesheet { 下一步,我们需要创建requestDOM方法,该方法将返回被传输的XML文档的XML::LibXML DOM表达式。由于我们的网关只适用于静态文件,我们需要使用XML::LibXML对文档进行解析,并返回结果树。 sub requestDOM { my $parser = XML::LibXML->new; 至此,我们的CGI脚本已经可以安全地在服务器的cgi-bin目录中安全地运行了,并在一些适当的目录中上载一些XML文档和一个或二个XSLT样式表。下面我们就可以开始检验我们的工作成果了。对http://localhost/cgi-bin/stylechooser/mydocs/somefile.xml的请求将会使互联网服务器从/opt/www/htdocs/xmldocs/目录中选取mydocs/somefile.xml文件,使用/opt/www/htdocs/stylesheets/中的样式表default.xsl对该文件进行转换,并将它传输给客户。 如果需要,我们可以扩充这一基本的框架,例如,可以在样式表选择CGI脚本程序添加一些查找组件,选择合适的样式表,可以设置或读取HTTP cookies,对网站进行修饰。 例2:一个简单的购物系统
与上个例子相同,这个应用程序中与CGI-BIN有关的部分仍然非常地少。我们所需要作的只不过是初始化CustomerOrder应用类并调用它的run()方法。这次,我们将CGI.pm中Vars作为%context的PARAMS域: use strict; my $app = CustomerOrder->new(); 在这个例子中,我们假定该应用中的产品信息存储在关系数据库中,产品清单不是太长,使我们在应用中不会出现多屏才能显示相关信息的麻烦:用户输入订购的产品数量的主要数据输入屏,显示订购单内容和所选物品总价格的确认屏,显示订单已经处理的提示。为了简单起见,我们在这里没有涉及送货和财务数据的输入等问题。 package CustomerOrder; use strict; @ISA = qw(CGI::XMLApplication); 在加载必要的模块和定义从CGI::XMLAplication中继承的类后,我们开始创建应用中与各种状态有关的事件调用。首先,我们必须通过创建registerEvents()方法注册这些事件。在本例中,我们将注册order_confirm 和order_send方法,这二个方法设置%context中的SCREENSTYLE域。稍后,我们将利用该属性定义在显示客户端的数据时应该使用三个XSLT样式表中的哪一个。 需要注意的是,这些事件将被映射到实现它们的实际的子程序中,子程序的命名规则是event_<事件名>,例如,order_confim事件是由event_order_confim执行的。另外,还需要注意的是,各种事件的选择是由CGI::XMLApplication根据其查找一个与注册事件同名的表格参数的能力进行的。例如,要执行order_confirm事件,表格组件中必须包含一个提交非空值的名字为order_confirm的表格域。 # 事件的注册和事件调用 sub registerEvents { sub event_order_confirm { sub event_order_send { 如果没有请求执行其他的事件,则缺省地执行event_default。在本例中,我们只使用它将SCREENSTYLE域设定为一个合适的值。 sub event_default { 每次请求都会执行event_init方法,而且总是在其他方法之前执行它,这使得它非常适合对应用中被其他事件使用的部分进行初始化。在本例中,我们使用它返回利用fetch_recordset()方法从数据库中获取的产品信息的、最初的DOM树。 sub event_init { state-handler方法完成后,我们需要执行必需的selectStylesheet和requestDOM方法。 与在第一个例子中一样,我们假设所有的应用的样式表都存储在服务器上相同的目录中。我们所需要作的是返回$context->{SCREENSTYLE}的值所指定的路线,并添加到末尾。 # app config and helpers 在研究requestDOM处理程序之前,我们先来详细地研究fetch_recordset helper方法。 需要记住的是,我们要做的工作是从一个关系数据库中选择所订购产品的有关信息,但传递给XSLT处理器的数据必须是DOM树。在本例中,我们不通过编程的方法,而是利用XML::Generator::DBI,它能够从执行SQL SELECT语句得到的数据中生成SAX数据。创建要求的DOM树就是建立XML::LibXML::SAX::Builder(它从SAX事件中创建XML::LibXML DOM树)的实例。 sub fetch_recordset { my $dbh =
DBI->connect('dbi:Oracle:webclients', my $builder = XML::LibXML::SAX::Builder->new(); my $dom = $gen->execute($sql) || die "Error Building DOM
Tree\n"; fetch_recordset方法完成了另一项很重要的任务,但它返回的DOM树只包含我们想向客户发送信息的一部分,我们还必须获取用户输入的产品数量,另外,还需要提供一个订购产品的总计。 sub requestDOM { 为了将当前的订货数量作为更大的文档的一部分,我们将遍历所有的产品元素,并在每行中添加<quantity>和<item-total>子元素。<quantity>的值可以从$context->{PARAMS}域获得。 foreach my $row
($root->findnodes('/document/productlist/product')) { # add the order quantity and item totals to the
tree. 最后,我们将增加一些有关订单的元信息,方法是在具有<order-total>元素的根元素中添加一个<instance-info>元素,该元素中包含有当前所选货物的总价值。 $grand_total ||= '0.00'; return $context->{DOMTREE}; 细心的读者可能已经注意到,我们这个非常简单的应用程序在order_send方法中没有作任何实际的事。决定如何处理这些数据是产品订购应用程序中与具体的购物网站最有关的部分。 结束语
如果您希望与本文章的作者或其所在机构,进一步交流,请联系:畅享网 姜小姐 jill.jiang@amt.com.cn | 021-51096826-112 | 在线联系 |
CIO职场,强者生存?在2008年,我们将继续看到CIO向商业运营方向发展。与此同时,我们也会看到商业管理人员将与技术管理人员一起竞争CIO岗位。 IT领导者的就职机会虽有不少,但其难度将会大幅提高。2…… |
|
|