The MVC model of Apache ofbiz source code interpretation

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:

[HTML]View Plaincopy print?

1. <request-map uri= "Createcreditcardandpostaladdress" >
2. <security https= "true" auth= "true"/>
3. <event type= "service" path= "invoke=" createcreditcardandaddress "/>
4. <response name= "Success" type= "Request" value= "Finalizeorder"/>
5. <response name= "Error" type= "View" value= "billsetting"/>
6. </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: [HTML]View Plaincopy print?

1. <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: [HTML]View Plaincopy print?

2. <!--event Handlers--
26. <!--view 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). [HTML]View Plaincopy print?

1. <request-map uri= "Createcreditcardandpostaladdress" >

Then, based on the configuration of its child element security, security checks are carried out:
[HTML]View Plaincopy print?

1. <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: [HTML]View Plaincopy print?

1. <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:

[HTML]View Plaincopy print?

1. <response name= "Success" type= "Request" value= "Finalizeorder"/>
2. <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):

[HTML]View Plaincopy print?

1. <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:

[HTML]View Plaincopy print?

1. <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:
[HTML]View Plaincopy print?

Screen

The above mentioned ofbiz in rendering the view, the use of an element named screen configuration:

[HTML]View Plaincopy print?

2. <screen name= "Billsettings" >
4. <section>
6. <actions>
8. <set field= "Steptitleid" value= "Orderorderentrypaymentsettings"/>
10. <set field= "Steplabelid" value= "Accountingpayment"/>
12. <script location= "Component://order/webapp/ordermgr/web-inf/actions/entry/billsettings.groovy"/>
14. </actions>
16. <widgets>
18. <decorator-screen name= "Commonordercheckoutdecorator" >
20. <decorator-section name= "Body" >
22. <platform-specific>
26. </platform-specific>
28. </decorator-section>
30. </decorator-screen>
32. </widgets>
34. </section>
36. </screen>

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:

[HTML]View Plaincopy print?

1. <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:

[HTML]View Plaincopy print?

1. <context-param>
2. <param-name>mainDecoratorLocation</param-name>
3. <param-value>component://order/widget/ordermgr/CommonScreens.xml</param-value>
4. <description>the location of the Main-decorator screens to use for this webapp; Referred to as a context variable in screen def XML files.</description>
5. </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:

1. 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.
2. 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