The MVC model of Apache ofbiz source code interpretation

In this article, we will explore the implementation mechanism of the MVC model of Apache OFBiz.

Brief introduction

The concept of model-view-controller is not too much to introduce here. If there is anything you want to know, please: Wikipedia. Here I only cite a picture of the item on Wikipedia to illustrate the interactive mechanism between the three component:

OFBiz implementation of MVC is the dependency between these three through XML. There are several key XML elements involved: <request-map/>,<view-map/>,

From the name of this file, the first impression that this seems to be just a definition of controller. But exactly, it defines the mapping between them, not only the mapping of the request, but also the mapping of the view, and a series of processors such as the view resolution processor, the event handler, and so on.

Let's first analyze each element and then concatenate them together to see how they work together.

Node Resolution REQUEST-MAP

You can think of it as a controller configuration, and if you know or use a struts configuration or springmvc annotation, you'll see that this definition is similar to them:

<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>

The element defines the mapping relationship for the request. It uses a property named URI that describes the request that the URI will map. The interior contains three commonly used child elements, namely: Security,event,response.

• Security: Indicates whether the URI should be of the appropriate level (if it should be HTTPS and whether permission checks are needed)
  
• Event: Events triggered by this request, which is discussed later in the explanation of handler
  
• Response: Specifies the configuration of the response
  

View-map A common VIEW-MAP configuration:

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

Included Properties:

• Name: The names of the current view-map, usually referenced by the Value property of the <request-map> child element <response>
  
• Type: What technology is used to show the view, usually screen, which is actually referring to the handler to be explained later
  
• Page: Specify the view layout file that is true for front-end presentation
  

Handler will roughly divide two types of handler:event and screen in OFBiz. In fact, I think the handler is understood here as the engine is more appropriate, because it is called handler easy to connect with the business, and if called the engine can be completely isolated from the business, it is only a purely technical components. It is easy to understand the definition of handler:

<!--event Handlers--
Handler contains the properties:

 
 

  
  
 
   
Name: Specifies the names of the handler, which are typically referenced by the Type property of the <request-map> child element's event and by the Type property of <view-map>.
 
   
Type: There are two types of values: request and view. The request should be for the processor of the event in <request-map>, and the view corresponds to the <view-map> processor
 
   
Class: Specifies the fully qualified name of the current processor implementation class
 
  
 
 
MVC string Below we received a request as an example of ofbiz, demonstrating the complete process of processing the request with the MVC model: First we assume that the OFBiz Web container receives the request: Createcreditcardandpostaladdress. The ofbiz is then Request-map defined in the controller configuration file under each app, Locate and match the mapping node with the URI Createcreditcardandpostaladdress (the node described in Request-map above).
<request-map uri= "Createcreditcardandpostaladdress" >

Then, based on the configuration of its child element security, security checks are carried out:
<security https= "true" auth= "true"/>

Because of the event element, an "event" is triggered here (note that there is not necessarily an event element). Here is a service that is invoked through the OFBiz serviceengine:
<event type= "service" path= "invoke=" createcreditcardandaddress "/>

After the service is called, a different response view is matched according to the results of the service execution:
<response name= "Success" type= "Request" value= "Finalizeorder"/><response name= "error" type= "View" value= " Billsetting "/>

Here (and typically) there are two different response configurations: Success,error. And the way they respond differently, we look at it separately:
If the event triggers the call to the Createcreditcardandaddress service, the return result is success, then a request will be triggered (type is the request indicating another trigger, but the request is a service-side request, A bit like the forward action in the servlet), the URI is Finalizeorder (which is the definition of another Request-map):
<request-map uri= "Finalizeorder" >

The semantics are: complete order creation.
If the event trigger invokes the Createcreditcardandaddress service with an error, it will present a view to the browser (type is view), and the view name is: billsetting. The next ofbiz is going to look for the view-map named: billsetting to find the following result:
<view-map name= "billsetting" type= "screen" page= "component://order/widget/ordermgr/orderentryorderscreens.xml# Billsettings "/>

Discover that it is a widget configuration (type screen represents an XML widget used in OFBiz), and the path to the configuration is: component://order/widget/ordermgr/ Screen with the name billsettings in the Orderentryorderscreens.xml file. Then use the handler named screen to parse the screen configuration:
Screen
The above mentioned ofbiz in rendering the view, the use of an element named screen configuration:
<screen Name= "Billsettings" > <section> <actions> <set field= "Steptitleid" value= "Orderorder Entrypaymentsettings "/> <set field=" steplabelid "value=" Accountingpayment "/> <script Loc ation= "Component://order/webapp/ordermgr/web-inf/actions/entry/billsettings.groovy"/> </actions> &l  t;widgets> <decorator-screen name= "Commonordercheckoutdecorator" > <decorator-section Name= "Body" > <platform-specific> 

This involves the widget layout design of the OFBiz front screen and form.
Section
It is a child element of screen, and a screen can contain n sections. And it can be made up of actions and widgets elements.
Action
Under the actions element, you can define a number of different kinds of action:

 
   

  
    
 
     
Label: Bind a value to a label
 
     
Entity action: Action with entity engine
 
     
Set action: Simple assignment and Groovy expression syntax
 
     
Script action: Invoking a Groovy script
 
     
Service action: Invoking a Services
 
    
 
   
Widgetswidgets is one of the features of the ofbiz layout, which splits a complete HTML page into small widgets, and the final page is composed of widgets.
First, a decorator-screen named: Commonordercheckoutdecorator is defined here. So-called Decorator-screen you can interpret it as a template or placeholder for a page. For example, for a page, part of the content and space is fixed, the main change is a specific area. When a new page is laid out, it is not necessary to repeat the HTML for each of its regions, and for public areas to refer directly to the already defined template.
For example, in the Commonordercheckoutdecorator decorator screen, which is defined, it also references a main-decorator of the app:
<decorator-screen name= "Main-decorator" location= "${parameters.maindecoratorlocation}" >

This is the outermost adorner template for the current app. This creates a two-tiered nesting relationship for the widget: billsettings references Commonordercheckoutdecorator, and Commonordercheckoutdecorator also quoted Main-decorator, this nested relationship, but also set up a page display of the link.
A common application whose maindecoratorloaction parameters can be found in the Context-param configuration in its web. xml:
<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>

Back to the point, in Billsettings's first decorator-screen:commonordercheckoutdecorator, there was also a decorator-section:body, which was a placeholder for the content area of the template.
The widget has a platform-specific child element inside it, which can be seen as a switch-case statement. The OFBiz Widget toolset does not restrict the way the render HTML UI is made. Theoretically, you can use any technique to render the content to the browser. Here the UI is made into HTML, and the HTML template is used, and the path to the template is specified by the Location property. Here the template uses Freemarker (which is also the most used template technology in ofbiz).
Data binding
In terms of front-end presentation, you need to bind the data to form a complete page, in addition to having a template made up of HTML tags.
OFBiz provides two ways to bind data:

 
   

  
    
 
     
Form-action: If you use a form widget, the best way to bind data is to take action child elements. This can be useful to help you enhance the reusability of the form.
 
     
Groovy Script Action: If you are using the Freemarker template, and the form is represented by the HTML native tag, the recommended way is to use groovy script to get the data and bind to the template to display, the example shown in this article is this pattern.
 
    
 
   


The MVC model of Apache ofbiz source code interpretation