Apache OFBiz源码解读之MVC模型

简介: 这篇文章我们来共同探讨一下Apache OFBiz的MVC模型的实现机制。 简介 对于Model-View-Controller的概念此处就不做过多介绍了。如果有想了解的请移步:维基百科。这里我只引用维基百科上关于该item的一张图片,来简单展示一下,这三个component之间的交互机制: OFBiz实现MVC是通过XML来串联这三者之间的依赖关系。

这篇文章我们来共同探讨一下Apache OFBiz的MVC模型的实现机制。

简介

对于Model-View-Controller的概念此处就不做过多介绍了。如果有想了解的请移步:维基百科。这里我只引用维基百科上关于该item的一张图片,来简单展示一下,这三个component之间的交互机制:


OFBiz实现MVC是通过XML来串联这三者之间的依赖关系。这里牵扯到几个关键的XML元素:<request-map />,<view-map />,<handler />。这三个XML元素的定义都位于applications/XXX/webapp/WEB-INF/controller.xml中。

从这个文件的命名来看,给人的第一感觉这似乎只是对controller的定义。但准确得说,它定义的是他们之间的映射关系,不仅包含了请求的映射关系,同时还包含了视图的映射关系,以及一系列的处理器比如视图解析处理器,事件处理器等。

我们先来分析每个元素,然后再将它们串联起来,看看它们联合起来是如何工作的。

节点解析

request-map

你可以将其理解为controller的配置,如果你了解或使用过struts的配置或springmvc的annotation,就会发现这个定义跟它们是很相似的:

<request-map uri="createCreditCardAndPostalAddress">
        <security https="true" auth="true"/>
        <event type="service" path="" invoke="createCreditCardAndAddress"/>
        <response name="success" type="request" value="finalizeOrder"/>
        <response name="error" type="view" value="billsetting"/>
    </request-map>

该元素定义了请求的映射关系。它使用名为uri的属性,表述该uri将要映射的请求。内部包含三个常用的子元素,分别是:security,event,response。

  • security:表示该uri应该对应的安全级别(是否应该是https的,是否要进行权限检查)
  • event:该请求触发的事件,这个后面在讲解handler的时候再谈
  • response:指定响应的配置

view-map

一个常见的view-map配置:
<view-map name="billsetting" type="screen" page="component://order/widget/ordermgr/OrderEntryOrderScreens.xml#BillSettings"/>

包含的属性:
  • name:当前view-map的名称,通常被<request-map>子元素<response>的value属性引用
  • type:其表示用什么技术展示视图,通常为screen,该值其实引用的是后面要讲解的handler
  • page:指定真实用于前端展示的视图布局文件

handler

在OFBiz中大致会划分两种类型的handler:event和screen。其实个人认为此处将handler理解为engine更为贴切一点,因为叫handler很容易跟业务联系到一起,而如果称之为engine则可以完全跟业务隔离开来,它只是纯技术组件而已。看看handler的定义就很容易理解了:
<!-- event handlers -->
    <handler name="java" type="request" class="org.ofbiz.webapp.event.JavaEventHandler"/>
    <handler name="soap" type="request" class="org.ofbiz.webapp.event.SOAPEventHandler"/>
    <handler name="xmlrpc" type="request" class="org.ofbiz.webapp.event.XmlRpcEventHandler"/>
    <handler name="service" type="request" class="org.ofbiz.webapp.event.ServiceEventHandler"/>
    <handler name="service-multi" type="request" class="org.ofbiz.webapp.event.ServiceMultiEventHandler"/>
    <handler name="service-stream" type="request" class="org.ofbiz.webapp.event.ServiceStreamHandler"/>
    <handler name="simple" type="request" class="org.ofbiz.webapp.event.SimpleEventHandler"/>
    <handler name="groovy" type="request" class="org.ofbiz.webapp.event.GroovyEventHandler"/>
    <handler name="rome" type="request" class="org.ofbiz.webapp.event.RomeEventHandler"/>
    <handler name="script" type="request" class="org.ofbiz.webapp.event.ScriptEventHandler"/>

    <!-- view handlers -->
    <handler name="screen" type="view" class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
    <handler name="screenxml" type="view" class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
    <handler name="screentext" type="view" class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
    <handler name="screencsv" type="view" class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
    <handler name="screenfop" type="view" class="org.ofbiz.widget.screen.ScreenFopViewHandler"/>
    <handler name="jsp" type="view" class="org.ofbiz.webapp.view.JspViewHandler"/>
    <handler name="ftl" type="view" class="org.ofbiz.webapp.ftl.FreeMarkerViewHandler"/>
    <handler name="http" type="view" class="org.ofbiz.webapp.view.HttpViewHandler"/>
    <handler name="birt" type="view" class="org.ofbiz.birt.webapp.view.BirtViewHandler"/>

handler包含的属性:
  • name:指定handler的名称,通常会被<request-map>子元素的event的type属性以及<view-map>的type属性所引用
  • type:有两种取值:request和view。request应对的是<request-map>中的event的处理器;view对应的是<view-map>的处理器
  • class:指定当前处理器实现类的完全限定名

mvc串接

下面我们以OFBiz收到一个请求为示例,展示其利用MVC模型处理请求的完整过程:
首先我们假设OFBiz web container收到请求:createCreditCardAndPostalAddress。然后OFBiz会根据每个app下面的controller配置文件中request-map定义,查找并匹配uri为createCreditCardAndPostalAddress的映射节点(就是上文中讲解request-map使用的节点)。
<request-map uri="createCreditCardAndPostalAddress">

然后根据其子元素security的配置,对其进行安全检查:
<security https="true" auth="true"/>

因为有event元素,那么此处会触发一个“事件”(注意,不一定会有event元素)。这里是通过ofbiz的ServiceEngine来调用一个service:
<event type="service" path="" invoke="createCreditCardAndAddress"/>

调用完该service后,根据service执行的结果,匹配不同的响应视图:

<response name="success" type="request" value="finalizeOrder"/>
<response name="error" type="view" value="billsetting"/>

这里(也是通常情况下)有两种不同的响应配置:success,error。而且他们的响应方式不同,我们分开来看:

如果event触发调用createCreditCardAndAddress服务的返回结果为success,那么将触发一个请求(type为request表示再次触发一个请求,但这个请求是服务端的请求,有点像servlet里的forward动作),uri为finalizeOrder(它是另一个request-map的定义):

<request-map uri="finalizeOrder">

其语义为:完成订单创建。

如果event触发调用createCreditCardAndAddress服务的返回结果为error,那么它将会向浏览器展示一个视图(type为view),而该视图的名称为:billsetting。那接下来ofbiz就去查找名为:billsetting的view-map,查找到如下的结果:

<view-map name="billsetting" type="screen" page="component://order/widget/ordermgr/OrderEntryOrderScreens.xml#BillSettings"/>

发现它是一个widget配置(type为screen表示OFBiz中采用的一种xml的widget),而该配置的路径为:component://order/widget/ordermgr/OrderEntryOrderScreens.xml文件中名称为BillSettings的screen。然后就利用名为screen的handler,来解析该screen配置:

<handler name="screen" type="view" class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>

screen

上面提到ofbiz在渲染视图的时候,采用了一个元素名为screen的配置:

<screen name="BillSettings">
    <section>
        <actions>
            <set field="stepTitleId" value="OrderOrderEntryPaymentSettings"/>
            <set field="stepLabelId" value="AccountingPayment"/>
            <script location="component://order/webapp/ordermgr/WEB-INF/actions/entry/BillSettings.groovy"/>
        </actions>
        <widgets>
            <decorator-screen name="CommonOrderCheckoutDecorator">
                <decorator-section name="body">
                  <platform-specific>
                        <html><html-template location="component://order/webapp/ordermgr/entry/billsettings.ftl"/></html>
                    </platform-specific>
                </decorator-section>
              </decorator-screen>
        </widgets>
    </section>
</screen>

这牵扯到OFBiz前端screen以及form的widget布局设计。

section

它是screen的子元素,一个screen可以包含n个section。而它可以又会由actions以及widgets元素组成。

action

在actions元素下,你可以定义若干个不同种类的action:

  • label:将值绑定到label
  • entity action:利用entity engine进行action操作
  • set action:简单的赋值以及groovy表达式语法
  • script action:调用一个groovy脚本
  • service action:调用一个服务

widgets

widgets是OFBiz布局的特点之一,它可以将一个完整的html页面拆分为一个个小块的widget,最终的页面是通过widget组合而成。

这里首先定义了一个名为:CommonOrderCheckoutDecorator的decorator-screen。所谓的decorator-screen你可以将其理解为页面的模板或者占位。比如,就一个页面而言,部分内容与空间是固定的,主要变化的是某个特定的区域。此时布局一个新页面的时候就没必要为其每个区域都重复编写html,对于公共区域直接引用已经定义好的模板即可。

比如此处的CommonOrderCheckoutDecorator装饰器screen,其定义中,它又引用了该app的一个main-decorator:

<decorator-screen name="main-decorator" location="${parameters.mainDecoratorLocation}">

这个是当前app最外层的装饰器模板。这样就形成了widget的两层嵌套关系:BillSettings引用了CommonOrderCheckoutDecorator,而CommonOrderCheckoutDecorator又引用了main-decorator,这种嵌套关系,也同时建立了页面显示的联系。

一个通常的应用,其mainDecoratorLoaction参数可以在其web.xml中的context-param配置中找到:

<context-param>
    <param-name>mainDecoratorLocation</param-name>
    <param-value>component://order/widget/ordermgr/CommonScreens.xml</param-value>
    <description>The location of the main-decorator screen to use for this webapp; referred to as a context variable in screen def XML files.</description>
</context-param>

回到正题,在BillSettings的第一个decorator-screen:CommonOrderCheckoutDecorator,还有一个decorator-section:body,它是对内容区域的模板占位。

widget内部拥有一个platform-specific子元素,它可以看做是一种switch-case语句。OFBiz widget 工具集没用对render html UI的方式进行限制。理论上,你可以采用任何技术来render浏览器能显示内容。在这里UI被render成HTML,而且还使用了html模板,该模板的路径通过location属性指定。此处该模板使用的是freemarker(这也是OFBiz中用得最多的一种模板技术)。

数据绑定

就前端展现而言,除了需要有由html标签组成的模板,还需要绑定数据才能形成完整的页面。

OFBiz提供了两种绑定数据的方式:

  1. form-action:如果你使用form widget,绑定数据的最好方式是采用action子元素。这可以有效得帮助你增强该form的复用性。
  2. groovy script action:如果你使用的是freemarker模板,此时form便是由html原生标签表示,那么推荐的方式是采用groovy脚本来获取数据并绑定至模板来显示,本文所举的示例就是这种模式。

原文发布时间为:2015-02-01

本文作者:vinoYang

本文来自云栖社区合作伙伴 CSDN博客,了解相关信息可以关注CSDN博客。
目录
相关文章
|
3月前
|
消息中间件 测试技术 Kafka
Apache RocketMQ 批处理模型演进之路
RocketMQ 早期批处理模型存在一定的约束条件,为进一步提升性能,RocketMQ 进行了索引构建流水线改造,同时 BatchCQ 模型和 AutoBatch 模型也优化了批处理流程,提供了更简便的使用体验,快点击本文查看详情及配置展示~
19768 78
|
6月前
|
SQL 存储 调度
从 Volcano 火山模型到 Pipeline 执行模型,阿里云数据库 SelectDB 内核 Apache Doris 执行模型的迭代
一个合适的执行模型对于提高查询效率和系统性能至关重要。本文全面剖析 Apache Doris Pipeline 执行模型的设计与改造历程,并在 2.1 版本对并发执行模式与调度模式进一步优化,解决了执行并发受限、执行及调度开销大等问题。
从 Volcano 火山模型到 Pipeline 执行模型,阿里云数据库 SelectDB 内核 Apache Doris 执行模型的迭代
|
6月前
|
设计模式 存储 前端开发
MVC(模型-视图-控制器)是一种在Web应用程序开发中广泛使用的软件设计模式
【5月更文挑战第12天】MVC模式是Web应用开发中的常见设计模式,将逻辑、数据和界面分离,提升代码可维护性和重用性。模型处理数据逻辑,视图展示数据,控制器协调用户输入与模型视图交互。优点包括代码分离、易维护、可扩展和组件重用,促进高效灵活的开发。
60 2
|
6月前
|
安全 数据管理 中间件
云LIS系统源码JavaScript+B/S架构MVC+SQLSugar医院版检验科云LIS系统源码 可提供演示
检验科云LIS系统源码是医疗机构信息化发展的重要趋势。通过云计算技术实现数据的集中管理和共享可以提高数据利用效率和安全性;通过高效灵活的系统设计和可扩展性可以满足不同医疗机构的需求;通过移动性和智能化可以提高医疗服务的精准度和效率;通过集成性可以实现医疗服务的协同性和效率。因此,多医院版检验科云LIS系统源码将成为未来医疗机构信息化发展的重要方向之一。
92 2
|
1月前
|
前端开发 Java
【案例+源码】详解MVC框架模式及其应用
【案例+源码】详解MVC框架模式及其应用
69 0
|
3月前
|
Apache 开发者 Java
Apache Wicket揭秘:如何巧妙利用模型与表单机制,实现Web应用高效开发?
【8月更文挑战第31天】本文深入探讨了Apache Wicket的模型与表单处理机制。Wicket作为一个组件化的Java Web框架,提供了多种模型实现,如CompoundPropertyModel等,充当组件与数据间的桥梁。文章通过示例介绍了模型创建及使用方法,并详细讲解了表单组件、提交处理及验证机制,帮助开发者更好地理解如何利用Wicket构建高效、易维护的Web应用程序。
47 0
|
5月前
|
设计模式 前端开发 安全
理解最常用的MVC分层模型及其变种
【6月更文挑战第24天】 本文介绍架构模式如MVC、MVVM和MVP是解决软件结构问题的通用方案。。每种模式有其优缺点,适用场景不同。
374 0
理解最常用的MVC分层模型及其变种
|
5月前
|
JSON 前端开发 API
Apache HttpClient调用Spring3 MVC Restful Web API演示
Apache HttpClient调用Spring3 MVC Restful Web API演示
45 1
|
5月前
|
安全 前端开发 测试技术
安全开发-PHP应用&模版引用&Smarty渲染&MVC模型&数据联动&RCE安全&TP框架&路由访问&对象操作&内置过滤绕过&核心漏洞
安全开发-PHP应用&模版引用&Smarty渲染&MVC模型&数据联动&RCE安全&TP框架&路由访问&对象操作&内置过滤绕过&核心漏洞
|
6月前
|
Java API Apache
【Apache ShenYu源码】看看贡献者如何实现支持提醒通知设计
在阅读中,还发现了有个html文件忘记加了开源协议,我们提下PR修复下,又收获了一次开源贡献!!PR提交戳这。
【Apache ShenYu源码】看看贡献者如何实现支持提醒通知设计

推荐镜像

更多
下一篇
无影云桌面