MVC model of Apache OFBiz source code interpretation

This element defines the mapping relationship of the request. It uses an attribute named uri that expresses the request that this uri will map. It contains three commonly used sub-elements, namely: security, event, and response.     security: Indicates the security level that the uri should correspond to (whether it should be https, whether to perform permission checking)
















    event: the event triggered by the request, this will be discussed later when the handler is explained
    : the configuration of the specified response

view-map
A common view-map configuration:
[html] view plain copy print? View the code snippet on the CODE derived to My snippet

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


contains properties:

    name: current view-map Name, which is usually referenced by the value attribute of the <request-map> sub-element <response>
    type: it indicates what technology is used to display the view, usually screen, which actually refers to the handler
    page to be explained later: specify the real for the front end The displayed view layout file

handler
is roughly divided into two types of handlers in OFBiz: event and screen. In fact, I personally think that it is more appropriate to understand the handler as the engine here, because it is easy to be linked to the business by calling the handler, and if it is called the engine, it can be completely isolated from the business, it is just a pure technical component. It 's easy to understand by looking at the definition of handler:
[html] view plain copy print? View snippet on CODE Derives to my snippet

    <! 
        <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"/> 














Let's take OFBiz receiving a request as an example to show the complete process of processing the request using the MVC model:
First, we assume that OFBiz web container receives the request: createCreditCardAndPostalAddress. Then OFBiz will find and match the mapping node whose uri is createCreditCardAndPostalAddress (that is, the node used by request-map explained above) according to the request-map definition in the controller configuration file under each app.
[html] view plain copy print? View the code snippet on CODE Derived to my code snippet

    <request-map uri="createCreditCardAndPostalAddress"> 


and then check it for security according to the configuration of its child element security:
[html] view plain copy print? View the code snippet on CODE Derived to my code snippet

    <security https="true" auth="true"/> 


Because there is an event element, an "event" will be triggered here (note that there may not be event element). Here is to call a service through ofbiz's ServiceEngine:
[html] view plain copy print? View code snippet on CODE derived to my code snippet

    <event type="service" path="" invoke="createCreditCardAndAddress"/> 



[html] view plain copy print? View code snippet on CODE derived to my code snippet

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


Here (and usually) there are two different response configurations: success, error. And their response methods are different, let's look at them separately:

if the event triggers the call to createCreditCardAndAddress and the return result is success, then a request will be triggered (the type of request means triggering a request again, but this request is a server-side request, a bit like a servlet forward action in ), uri is finalizeOrder (it is the definition of another request-map):
[html] view plain copy print? View code snippet on CODE derived to my code snippet

    <request-map uri="finalizeOrder" > 


Its semantics are: complete order creation.

If the event triggers a call to the createCreditCardAndAddress service and the return result is error, then it will display a view (type is view) to the browser, and the name of the view is: billsetting. Then ofbiz went to look for the view-map named: billsetting, and found the following results:
[html] view plain copy print? View the code snippet on CODE derived from my code snippet

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


found that it is a widget configuration (type is screen means that OFBiz adopts A widget of xml), and the path of the configuration is: the screen named BillSettings in the component://order/widget/ordermgr/OrderEntryOrderScreens.xml file. Then use the handler named screen to parse the screen configuration:
[html] view plain copy print? Viewing the code slice on CODE is derived from my code slice

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

screen

As mentioned above, ofbiz uses a configuration with an element named screen when rendering the view:
[html] view plain copy print? View the code snippet on CODE derived from me Code snippet for

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


This involves the layout design of OFBiz front-end screen and form widgets.
Section

is a child element of screen, and a screen can contain n sections. In turn, it can be composed of actions and widgets elements.
action

Under the actions element, you can define several different kinds of actions:

    label: bind the value to the label
    entity action: use the entity engine to perform actions
    set action: simple assignment and groovy expression syntax
    script action: call a groovy Script
    service action: Calling a service

widgets
widgets is one of the features of OFBiz layout, it can split a complete html page into small widgets, and the final page is composed of widgets.

Here first defines a decorator-screen named: CommonOrderCheckoutDecorator. The so-called decorator-screen can be understood as a template or placeholder for the page. For example, as far as a page is concerned, part of the content and space are fixed, and the main change is a specific area. At this time, when laying out a new page, there is no need to repeatedly write html for each area, and you can directly refer to the defined template for the public area.

For example, the CommonOrderCheckoutDecorator decorator screen here, in its definition, it references a main-decorator of the app:
[html] view plain copy print? View the code slice on CODE derived from my code slice

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


This is the outermost decorator template of the current app. In this way, a two-level nesting relationship of widgets is formed: BillSettings refers to CommonOrderCheckoutDecorator, and CommonOrderCheckoutDecorator refers to main-decorator. This nesting relationship also establishes the connection of page display.

A usual application whose mainDecoratorLoaction parameter can be found in the context-param configuration in its web.xml:
[html] view plain copy print? View snippet on CODE Derive to my snippet

    <context-param> 















        form-action: If you are using a form widget, the best way to bind data is to use an action child element. This can effectively help you enhance the reusability of the form.
        groovy script action: If you are using the freemarker template, and the form is represented by html native tags, the recommended way is to use the groovy script to obtain data and bind it to the template for display. The example in this article is this model.