OFBIZ应用程序结构

1）ofbiz可以整个看作一个大服务容器。

2）web容器中包含的服务顶级目录是application.

application下是如product,workeffort ，securityext 等子服务 程序。为什么叫子服务，而不是子web应用程序呢？请接着来看下面的例子。

3）程序结构。我们从一个例子分析，workeffort服务的结构：

-workeffor

--build

--config

--data

--entidydef//存放数据模型定义的xml文件

--script

--servicedef//存放service定义的xml文件

--testdef

--webapp//子web程序

----ical

------WEB-INF

--------web.xml

----workeffor

------WEB-INF

--------web.xml

--------controller.xml //提供Request URL Mappings请求路径相关

--wedget //web子程序返回的UI界面相关，一般使用freemarker

--build.xml

--component-load.xml / /可以申明此子服务的服务可以被其它子服务调用，如中的workeffort能被 product调用。

--ofbiz-component.xml/ /子服务申明文件，主要内容包括四部分。

4）声明控制器。 ofbiz-component.xml： 主要声明workeffort 所有服务的文件位置。

一是配置文件夹classpath，指向上面列举的文件夹：

   <classpath


 type="jar" location="build/lib/*"/>
    <classpath type="dir" location="config"/>
    <classpath type="dir" location="script"/>

二是数据模型entity声明文件的位置：

entity-resource type="model" reader-name="main" loader="main" location="entitydef/entitymodel.xml



"/>
    <entity


-resource type="model" reader-name="main" loader="main" location="entitydef/entitymodel_old.xml"/>
    <entity-resource type="model" reader-name="main" loader="main" location="entitydef/entitymodel_view.xml"/>
    <entity-resource type="eca" reader-name="main" loader="main" location="entitydef/eecas.xml"/>

三是web service的申明：

  <service


-resource type="model" loader="main" location="servicedef/services.xml


"/>
    <service-resource type="model" loader="main" location="servicedef/services_timesheet.xml"/>
    <service-resource type="eca" loader="main" location="servicedef/secas.xml"/>

四是子服务的子webapp的位置：如上例子有两个ical和workeffor

   <webapp


 name="workeffort"
        title="WorkEffort"
        server="default-server"
        location="webapp/workeffort"
        base-permission="OFBTOOLS,WORKEFFORTMGR"
        mount-point="/workeffort"/>

     <webapp name="ical"
        title="iCalendar"
        app-bar-display="false"
        server="default-server"
        location="webapp/ical"
        mount-point="/iCalendar"/>

5）加载顺序。很容易看出先ofbiz-component.xml,然后加载其他问文件。

6）调用控制器。看到现在我们发现一个问题，上面的都是声明，最关键的调用控制是怎么发生的？浏览器访问时，url解析是怎么申明的呢？

controller.xml， 就是他了，他负责寻址，调用业务类或者业务服务类处理，并返回UI.

看个例子，注意下面的event标签的type和invoke：

    <request-map uri="createWorkEffortAssoc">
        <security https="true" auth="true"/>
        <event type="service" invoke="createWorkEffortAssoc"/>
        <response name="success" type="view" value="EditWorkEffortAssoc"/>
        <response name="error" type="view" value="AddWorkEffortAssoc"/>
    </request-map>

当请求createWorkEffortAssoc时，调用servicedef文件夹下createWorkEffortAssoc。并返回到wedget下的申明的view视图EditWorkEffortAssoc或者AddWorkEffortAssoc，视图一般用freemarker，解析返回就是一个html.文件

    <request-map uri="changeDelegator">
        <event type="java" path="org.ofbiz.webapp.event.CoreEvents" invoke="changeDelegator"/>
        <response name="success" type="view" value="main"/>
        <response name="error" type="view" value="error"/>
    </request-map>

当请求createWorkEffortAssoc时，直接调用类org.ofbiz.webapp.event.CoreEvents的changeDelegator方法。并返回到wedget下的申明的view视图EditWorkEffortAssoc或者AddWorkEffortAssoc，视图一般用freemarker，解析返回就是一个html.文件。

7）最后再回答那个问题：application下为什么叫子服务，而不是子web应用程序呢？

一是从文件结构就能看出，<web-app>也被当作了服务的中一类。

二是分析ofbiz-component.xml,里面可以不使用web-aap标签，此时就是一个纯粹的web service服务器了，如securityext。

OFBIZ应用程序结构

猜你喜欢