Webx学习（一）

时间：2020-12-27 11:03:32

什么是webx

Webx3_Guide_Book中是这样介绍的：

Webx是一套基于Java Servlet API的通用Web框架。

Webx致力于提供一套极具扩展性的机制。来满足Web应用不断变化和发展的需求。而SpringExt正是这样的扩展性的基石。SpringExt扩展了Spring，在Spring的基础上提供了一种扩展功能的新方法。

这也说明。webx是在springExt的基础上建立起来的一套web服务框架。

它封装了servlet规则。细化了普通情况下的filter，通过配置文件pipeline.xml和强化过的RequestContexts，将一个请求的路径和处理过程展现。有关这两个是什么和它们的用法后面再说。

该框架不但定义了请求分发机制，更对前端的页面展示层进行模板式的定义：使用default.vm、index.vm、register.vm等类型的自己定义模板与analyzeURL机制进行交互。形成从前端到后台的“总体一条龙”的流程。

在Webx中。约定胜于配置。规则较多，但我相信理解之后便能够*运用（我们学习不论什么东西都要先了解它的规则。这是必定的一步）。

Webx的必备组件

  • spring核心框架
  • webx框架依赖（com.alibaba.citrus）当中包括了重要的WebxContextLoaderListener和LogConfiguratorListener
  • pipeline及映射规范
  • 模板规范
  • 配置项

spring核心框架

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-core</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-beans</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-aop</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-context</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-context-support</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-tx</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-jdbc</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-orm</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-web</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-webmvc</artifactId>

            <version>${spring-version}</version>

        </dependency>

        <dependency>

            <groupId>org.springframework</groupId>

            <artifactId>spring-test</artifactId>

            <version>${spring-version}</version>

        </dependency>

$spring-version可在标签中可通过<spring-version></spring-version>配置。

webx框架依赖

<dependency>

    <groupId>com.alibaba.citrus</groupId>

    <artifactId>citrus-webx-all</artifactId>

    <version>${webx-version}</version>

</dependency>

代碼包名規則

通过pipeline的analysisURL模块解析出target之后，会依据pipline-velves制定的规则分发。

这时。须要知道什么样的target会相应到什么样的流程中去，这个相应过程的识别，是依据包名的约定来定义的。也即是约定大于配置的一个体现。

对于包名的配置项在webx.xml和webx-*.xml中定义。

<!-- 装载模块。 -->

<services:module-loader>

    <ml-factories:class-modules>

        <search-packages type="$1"

            packages="todolist.module.*" />

    </ml-factories:class-modules>

</services:module-loader>

packages所指的就是用于匹配相应规则的包，$1直接匹配到screen.xxx.java或action.xxx.java等等。

而在pipeline.xml中制定映射规则包括：

<pl-valves:performAction />

performAction：在webx中主要是用来处理提交的表单，将表单类传给java类。运行相应的处理方法，然后返回或者重定向。

<pl-valves:performTemplateScreen />

performTemplateScreen：将target映射成module包下的screen.xxx类。

详见附件的第四章WebxTurbine。

<pl-valves:renderTemplate />

rendertemplate:将target映射到webroot下的各个模板上。

注：这是映射的不是类，而是模板了，也就是带着数据等開始渲染模板。

详见第四章WebxTurbine。

这里可能会有一个误区。依据我的使用历程，发现performAction、performtemplateScreen和renderTemplate这三个基本方法，凡是perform开头的都是映射到java类的。

我開始的时候会觉得performTemplateScreen是直接映射到app/templates/screen中的模板去，后来才发现这个问题。

仅仅有render相关的才是渲染模板。一般使用renderTemplate的应该是运行完perform*之后或者是首页——直接渲染模板。

pipeline

Pipeline不仅能够控制流程的中断或继续。还能够实现子流程、循环、条件转移、异常处理等更精细的流程控制。Pipeline服务甚至能够运用在非WEB的环境中。

上述包名规则的定制就是为了pipeline服务中使用perform*和 renderTemplate等等去使用的。

模板规范

正如上述所说，在renderTemplate的时候就须要用到模板的规范了，他能够使得类中处理得到的数据和模板相应起来。

模板文件夹有这几个要素：

webroot下以应用名为子文件夹（如app）

  • webroot/common
  • webroot/app
  • webroot/WEB-INF

当中重点讲app下模板，common的与app大体一致。

  • app/templates/layout
  • app/templates/screen

screen下能够自己定义文件夹，该自己定义文件夹在使用外部重定向的时候须要跟设置的setTarget（）相符。

如：screen/form/register.vm

则nav.redirectedTo(“appLink”).setTarget（“form/register”）即锁定到了该register.vm。

在renderTemplate时，先渲染screen中的内容，然后出来寻找layout。终于将组装好的整个页面呈现。

详见附件第四章WebTurbine——renderTemplate。

配置项

上述几项已经基本将pipeline.xml的主要部分做了说明。

以下看一些固有的配置项和自己定义（app）配置项。

WEB-INF下

  • web.xml
  • webx.xml
  • webx-*.xml
  • logback.xml

WEB-INF/common下

  • pipeline.xml
  • pipeline-execption.xml
  • resource.xml
  • uris.xml
  • webx-component.xml
  • webx-component-and-root.xml

WEB-INF/app下

- form.xml

下一节的主要任务是弄清楚这些配置和之间的关系。

附：

之前讲到了pipeline和requestContext将传统的filter细分为两个比較独立的职能。以下是对webx中requestContext的简介。

RequestContexts则负责訪问和改动request和response，但不负责改变requese的运行流程。

RequestContexts服务中的每个环节的RequestContext之间并不是全然独立、互不干涉的。每个request context能够訪问它所依赖的其他request context中的状态。

详见附件第六章——Filter、Request Contexts和Pipeline。

附件：Webx3GuideBook

相关文章