Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleSource Code!

OFBiz
Download Apache OFBiz™
OFBiz Source Repository and Access

Tutorial
The source code for the Practice Application demonstrated in this tutorial can be downloaded from here: Download Source Code

Framework Introduction Videos
These are old but still worth watching if you want. In parallel with the development of this application,you can view OFBiz videos, which are available at Framework Introduction Videos and Diagrams,

Table of Contents

Creating Practice Application (Hello World...)

...

  1. Now it is time to create a decorator for the screens in this application. Create a file named CommonScreens.xml in the "widget" directory. This file will contain the common screens which will be used throughout the entire application. A common screen may have a header and footer included so any other screens that use it as a decorator will also have those items. For this you can take reference from the CommonScreens.xml file in the "example" component.
    CommonScreens.xml file code will be:

    Code Block
     <screen name="CommonPracticeDecorator">
          <section>
              <widgets>
                   <decorator-section-include name="body"/>                     
              </widgets>
          </section>
    </screen>
    

    Refer to the "CommonScreens.xml" file in the "Example" component to see usage of main-decorator.  Two important readings at this moment are Understanding the OFBiz Widget Toolkit and "The Decorator" section in FAQ.
    Add reference in web.xml to the CommonScreens.xml

    Code Block
    <context-param>
         <param-name>commonDecoratorLocation</param-name>
         <param-value>component://practice/webapp/practice/widget/CommonScreens.xml</param-value>
         <description>The location of the common-decorator screen to use for this webapp; referred to as a context variable in screen def XML files.</description>
    </context-param>
    
  2. Anchor
    include-menu
    include-menu
    Create a menu for this application. For this create a file by name PracticeMenus.xml in "widget" directory of you component. For this take a reference from ExampleMenus.xml file of "example" component.

    Code Block
    <?xml version="1.0" encoding="UTF-8"?>
    <menus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-menu.xsd">
        <menu name="PracticeAppBar" title="PracticeApplication" extends="CommonAppBarMenu" extends-resource="component://common/widget/CommonMenus.xml">
            <menu-item name="main" title="Main"><link target="main"/></menu-item>
        </menu>
    </menus>
    

    Include this menus file in your CommonPracticeDecorator as follows:

    Code Block
    <screen name="CommonPracticeDecorator">
            <section>
                <widgets>
                    <include-menu location="component://practice/webapp/practice/widget/PracticeMenus.xml" name="PracticeAppBar"/>
                    <decorator-section-include name="body"/>
                </widgets>
            </section>
        </screen>
    
  3. Create the sub-directory "actions" inside the WEB-INF directory.
    In this directory we will create the scripting files. Scripting files are used to prepare data on fly. These files will be groovy files. Earlier we were using bsh(beanshell) files. This is a script which is used to fetch the data from database on the fly for the UI.
    Reference : Tips & Tricks while working with Groovy & http://groovy.codehaus.org/. While working in groovy always be conscious about the imported classes and packages. Import only those which have been used in your file. For putting log messages use methods from "Debug" class just do this practice from the beginning itself. So create a file by name Person.groovy in this actions directory which will be fetching all the records from the entity "Person". At this moment this is really going to be the small code for doing this (a single line) like

    Code Block
    context.persons = delegator.findList("Person", null, null, null, null, false);
    

    The above statement will fetch all the records from the Person entity and will put them in context by the name persons. Now this list by the name person will be iterated in the ftl file to show the records.
    At this place an important reading is available at : Which variables are available in screen context?

  4. Now in webapp "practice" create one ftl file by name "Person.ftl" which will be used to show the data fetched by groovy file.
    Reference : http://freemarker.sourceforge.net/docs/
    At this moment you need only to iterate the list of persons which is there in the context. The only code that is needed to that is:

    Code Block
    <#if persons?has_content>
      <h2>Some of the people who visited our site are:</h2>
      <br>
      <ul>
        <#list persons as person>
          <li>${person.firstName?if_exists} ${person.lastName?if_exists}</li>
        </#list>
      </ul>
    </#if>
    
  5. Now create a new screen by name "person" in PracticeScreens.xml file and also create a new menu item in PracticeMenus.xml file.
    PracticeScreens.xml new screen entry will be:

    Code Block
        <screen name="person">
            <section>
                <actions>
                    <script location="component://practice/webapp/practice/WEB-INF/actions/Person.groovy"/>
                </actions>
                <widgets>
                    <decorator-screen name="CommonPracticeDecorator" location="${parameters.commonDecoratorLocation}">
                        <decorator-section name="body">
                            <platform-specific>
                                <html>
                                    <html-template location="component://practice/webapp/practice/Person.ftl"/>
                                </html>
                            </platform-specific>
                        </decorator-section>
                    </decorator-screen>       
                </widgets>
            </section>
        </screen>
    
  6. Now change the controller.xml file so it points to the new screen, as we did earlier.
    Now again run the application and observe the results by giving http://localhost:8080/practice/control/person .

    Tip
    titleHint

    If the output screen does not contain the menu as shown below, you will most likely need to change auth="true" to auth="false" in your controller.xml for the menu to come up.

    Output Screen :

...

Events can be written in Java and minilang both. Now the next development which you are going to do will be writting these events.
Events are used for the validation and conversion using Simple Map Processor. The Simple Map Processor Mini-Language performs two primary tasks: validation and conversion. It does this in a context of moving values from one Map to another. The input map will commonly contain Strings, but can contain other object types like Integer, Long, Float, Double, java.sql.Date, Time, and Timestamp.
Before moving any further an important link to go through is : Mini-Language Guide (deprecatedVersion 2 - Deprecated), Old link(http://ofbiz.apache.org/docs/minilang.html). For making an understanding with it implementation will be done by performing following steps:

...

ECA : It is a combinition of 3 things: an event, conditions per event, and actions per event. It is a rule used to trigger an action upon the execution of an event when certain conditions are met. When a service is called for example a lookup is performed to see if any ECAs are defined for this event. Events include before authentication, before IN parameter validation, before actual service invocation, before OUT parameter validation, before transaction commit, or before the service returns. Next, each condition in the ECA definition is evaluated and if all come back as true, each action is performed. An action is just a service which must be defined to work with the parameters already in the service's context. There is no limit to the number of conditions or actions each ECA may define.
For more details on this visit :  Service Engine Guide

  1. SECA (Service Event Condition Action) : This is used when we want to trigger another service(action) on the execution of a service when certain conditions are met.
  2. EECA (Entity Event Condition Action) : This is used when we want to trigger a service on the creation of a record for an entity when certain conditions are met.
    For the implementation of ECA again we will be following the same approach for screens, menus by following steps:

...