THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
3. In <webapp> tag, we have different attributes and their purpose is as follows:
| Code Block |
|---|
<webapp name="practice"
title="Practice"
server="default-server"
base-permission="OFBTOOLS"
location="webapp/practice"
mount-point="/practice"
app-bar-display="false"/>
|
...
Step - 6 : Move up one level and create a new directory named 'error'(hot-deploy/practice/webapp/practice/error).
Step - 6.a : Create a file error.jsp inside the "error" directory. Contents of this file can be taken from any of the existing component e.g. example component.
The location of your error page will be specified in the beginning of your controller.xml file like <errorpage>/error/error.jsp</errorpage> . You will need to make or copy over a /webapp/practice/error/error.jsp page to show an error message to the user.
Step - 7 : Create a sub-directory inside your component directory "practice" named "widget"(hot-deploy/practice/widget).
This directory will contain your forms and screens which will be created for UI.
Step - 8 : Create a file inside the directory "widget" named "PracticeScreens.xml".
Contents of this file can be taken from any of the existing component e.g. example component.
As now onwards you will be able to create screens views so an important reading at this place will be Best Practices Guide . On this page there links to following:
- HTML and CSS Best Practices
- Managing Your Source Differences
- Methodology Recommendations
- User Interface Layout Best Practices
All these readings will be really of help.
Very first screen will be like :Code Block <?xml version="1.0" encoding="UTF-8"?> <screens xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-screen.xsd"> <screen name="main"> <section> <widgets> <label text="This is first practice"/> </widgets> </section> </screen> </screens>
Step - 9 : Now that we have the basic elements in place lets review the basic flow no matter how large or complex your component gets. First a request will be made by a browser to see a specific resource. Take for example the request:
"localhost:8080/practice/control/main" 1. When OFBiz sees this request it will look at the /practice section first. Because in our ofbiz-component.xml file we said our webapps mount point would be /practice. Now OFBiz knows that our practice component will handle the rest of the request.
2. OFBiz will then look at our controller.xml file. Inside our controller.xml file we have request-maps and view-maps. If it finds a request-map with the name 'main' it will use the associated view-map, as follows. The request-map can either specify a view, or as we will see later an event or a service. If it specifies a view it will look further down in the controller.xml file and see if there is a view-map with the name specified by the value tag in the request-map.
3. For now we will keep it simple and assume that all the views go to a type=screen. If this is the case then the page tag will specify a path to a screen definition file as well as a screen name to display after the "#" sign.
Step - 10 : Now its the time to run you first practice application:
Start server by : java -Xmx256M -jar ofbiz.jar (the -Xmx256M command just ensures that the program has enough memory) Then hit the url http://localhost:8080/practice/control/main in your browser.
Browser should show "This is first practice"
Output Screen :
Step - 11 : Now create a file in webapp directory "practice" by name index.jsp (Contents of this file can be taken from "example" component), this file is responsible for redirecting the response to control/main if you give url http://localhost:8080/practice/ and if you give url like http://localhost:8080/practice/unknown/requestit will be redirected to the redirectPath specified in web.xml. In that case, ContextFilter filter out the request and use this redirect path to redirect the request.Part - 2
...
Step - 1 : Now its the time to create a decorator for the screens in this application so for that create a file by name CommonScreens.xml file in "widget" directory. This file will be containing the common screens which will be used through out the whole application. E.g. A common screen may have header and footer included in it so which ever is the screen will be using it as a decorator will be having those in common. For this you can take reference from CommonScreens.xml file of "example" component.
An important reading at this moment is at Understanding the OFBiz Widget Toolkit another is the FAQ in this you can read the contents under heading "The Decorator".
Step - 2 : 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="MainAppBar" title="PracticeApplication" extends="CommonAppBarMenu" extends-resource="component://common/widget/CommonMenus.xml">
<menu-item name="main" title="Main"><link target="main"/></menu-item>
</menu>
</menus>
|
Step - 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
...
Step - 5 : Now create a new screen by name "person" in PracticeScreens.xml file and also create a new menu item in PracticeMenus.xml file.
Step - 6 : Now do the needful for rendering this screen in controller.xml file as we did earlier.
Now again run the application and see the results.
Output: 
Now moving to create a form for showing the content of Person entity on the screen:(Using Form Widget)
...
Step - 3: Include this UI Label resource in your main decorator screen which you created earlier and use these one or two ui labels which you are having now.Step - 4 : Use those 2 UI labels at appropriate places.
Note : Always search first for any existing Ui label in ofbiz and if you don't find it there then only create new one.
Now its time to make this practice application secure by checking authentication (user login):
...
Now run your application and observe the difference. you can login by user name : admin and pwd: ofbizHere we should understand why we had given the permission "OFBTOOLS" in base-permission in ofbiz-component.xml file. To understand this please read following carefully and perform steps as mentioned:
Confirm that user 'admin' has the 'OFBTOOLS' permission.
Step : 1 - Login into partymanager to confirm that the user admin has the required permission https://127.0.0.1:8443/partymgr/control/main
Step : 2 - Once your logged in search for the user by typing 'admin' in the User Login field and then clicking the Lookup Party button.
Step : 3 - This does a wild char* search and you should see multiple users returned.Click the 'Details' button for the admin user.
Note : Important point to note here is that the person 'Mr. THE PRIVILEGED ADMINISTRATOR' has a partyid admin has multiple logins as listed in the
User Name(s) form.
Step : 4 - We interested in the admin user login so click on the 'Security Groups' button and confirm that the use 'admin' is part of the 'FULLADMIN' group. The Groups that the user belongs to is shown in the bottom list form Drill down on the FULLADMIN.
Step : 5 - Click on the Permissions tab. This tab shows all the permissions for the FULLADMIN security group. Navigate between the permissions till you find the OFBTOOLS permissions.
'OFBTOOLS_VIEW Permission to access the Stock OFBiz Manager Applications.' This confirms that the userlogin 'admin' has the permission 'OFBTOOLS'
Step : 6 - Take a moment to review the entity model as it relates to users and permissions. The arrow represents the many side of the relationship.An really important reading at this moment is at : OFBiz Security
Part - 3
Writing CRUD operations:
...
So whenever you make any change in any service definition then you must restart the server to have changes in effect.
Writing CRUD operations for Party entity:
...
engine="entity-auto" invoke="create" play the role for creating the records for the default-entity "Example."
Here for practice you may go by following further steps those steps will help you in understanding the concept then onwards you can practice the pattern given above in your code only.
Writing CRUD operations for Person entity:
...
Here the path is the classpath in which this event is defined.
The file name will be PracticeEvents.java and will be created at practice/src/org/hotwax/practice.
Simple Event
Step - 6 : Now in the script/org/hotwax/practice/ create one file by name PracticeEvents.xml.
Step - 7 : Write the event in PracticeEvents.xml file by name createPracticePersonSimpleEvent.(For reference you can go through the event "createUser" from UserEvents.xml from party component)
The event which you will be writing should be the simple one as you just have to process 5 fields coming from the form which are salutation, firstName, middleName, lastName, suffix. and then you have to call the createPracticePerson service.
For processing the field you will be using simple map processor as you have read earlier.
Follow these steps for writing the event:
7.a : Process fields coming from the form like:
...
7.b : Create some Ui labels for showing them in fail-property like PracticeFirstNameMissingError.
7.c : Now call service createPracticePerson service by passing out map which is obtained after processing fields as a in map to the service.
Part - 4
Java Event:
Here the java event which you will be writing will be fairly simple. For reference you can check any of the *Events.java file.
Step - 1 : The contents will be :
...
So create a file by name build.xml and then compile it. It will create a build directory in your component directory which will be containing all *.jar and class files after compilation. For the content of build.xml file you can refere example component.
For running the simple event don't forget to make an entry for <classpath type="dir" location="script"/> in ofbiz-component.xml file.
For running the java event make an entry <classpath type="jar" location="build/lib/*"/> in ofbiz-component.xml file.
ECA(Event Condition Action):
...
Step - 3 : Do an entry in ofbiz-component.xml file for this seca definition to to be loaded. It will be :
<service-resource type="eca" loader="main" location="servicedef/secas.xml"/>
Don't forget to restart the server after doing this entry.
Now run the service through form and check the records in PartyRole entity. You will find a role is set for the party created because synchrounously you have triggered another service by seca rule for setting up the role for the party created.
EECA :
Step - 1 : For this you have to write another service by name "createPartyRoleCustomer", which will be setting the role for the party which will be created means when a record for the entity "Party" will be created this service will be triggered for setting a role customer for that party. The service "createPartyRoleCustomer" will be similar to "createPartyRoleVisitor".
Step - 2 : Now you have to create a file by name "eecas.xml" in "entitydef" directory, which will be in your component directory "practice". Eeca definition will come here. (Take reference from eecas.xml of "accounting" component). This will be :
...
Don't forget to restart the server after doing this entry.
Now run the service through form and check the records in PartyRole entity. You will find a role is set for the party created because synchrounously you have triggered a service by eeca rule for setting up the role for the party created.
The main difference here is that you are triggering a service when an operation performed on the entity. In our case it is "create".
Note : Here you have created a saparate menu to understand the concept separately. As you written seca for the service "createPracticePerson", so where ever in your practice application you will be calling this service that seca will trigger "createPartyRoleVisitor" and on the other hand when a party will be created "createPartyRoleCustomer" will be triggered.
Group Service:
Group services are used to call more then one services as a group. Service groups are a set of services which should run when calling the initial service. You define a service using the group service engine, and include all the parameters/attributes needed for all the services in the group. The location attribute is not needed for groupservices, the invoke attribute defines the name of the group to run. When this service is invoked the group is called and the services defined in the group are called as defined.
For mor details on this visit : http://docs.ofbiz.org/display/OFBTECH/Service+Engine+Guide
For the implementation of Group service follow these steps:
Step - 1 : Add another menu item to applicatoin menu bar by name "Group Service".(Do the needful entries for target in controller.xml)
Step - 2 : Now create new screen and a form for creation of the person because the target for the form will be the group service which we will be defining.
Note : Now the time is to define the group service. We will be defining the group service for the services which we have implemented for this practice application.
Step - 3 : You will be defining the service group in services.xml file.(Take reference from services.xml of party component).
Just write one more service which will be setting the role "CLIENT" for the party which will be created by createPracticePerson Service.
Create a group service by name "partyGroup" like :
...
Don't forget to restart the server before testing it.
Interface:
The interface service engine has been implemented to help with defining services which share a number of the same parameters. An interface service cannot be invoked, but rather is a defined service which other services inherit from. Each interface service will be defined using the interface engine.
For more details on this visit : http://docs.ofbiz.org/display/OFBTECH/Service+Engine+Guide
For implemeting the interface follow these steps:
Step - 1 : Add another menu item to applicatoin menu bar by name "Interface".(Do the needful entries for target in controller.xml)
Step - 2 : Create new screen, form and service for creating a person. Here service will implement the interface. (For creating interface take reference from services_fixedasset.xml of accounting component) it will be like :
...
Here we are implementing an interface and overriding the behaviour of the attribute "suffix", which will have effect when this service will be in action.
Implementation of service createPracticePersonInterfaceService will be the same as createPracticePerson.
Don't forget to restart the server after this implementation.
Part - 5
Creating new entity:
...
That implies that when ever you do a change you need to restart the server to have those changes in effect.
At this place an important reading is at http://docs.ofbiz.org/display/OFBTECH/General+Entity+Overview.
You will rarely find this way to define new entity because you are already having entities there in OFBiz already defined which will be useful for the conduction of your business process. Though you may feel at some place to add more fields to an existing entity so how can you do that? The next step will show you the way how you can extend an entity for your customized needs.
Earlier we used to have one more file in same directory by name entitygroup.xml which not needed any more because code is checked in to the trunk for this.
Extending an existing entity:
...
As an example of this you can refer entitymodel.xml file from party component.
This is the simplest form it can be more complex. This will add up one more field to the entity you already have. Now it depends which field you want for your custom needs. Here you can also defined relation of this field with other entities you want. But before doing this you should search extesively may be you will be adding a field for a purpose and there is already a field which will serve the purpose, so be concisous about this. Also go for a extensive study of data model then do this.
For entity engine configuration dont forget to read : Entity Engine Configuration Guide
Preparing Data For Custom Application:
...
After doing this entry when you will run the command ant run-install to load demo data then the data from this file will be loaded as demo data and once you start the server you can see this record added for person by going to Person Form in practice application or you can prefer to go to https://localhost:8443/webtools/control/entitymaint and find each entity and check the records have gone in the database or not.
Conclusion:
If you have followed all the steps and developed practice application from this application then this will really help you in understanding other implementations in OFBiz. These things are basic foundation of working in OFBiz. Now you know that how you can start the development in OFBiz. Don't leave the extra links provided in this tutorial as they will really help you a lot in understanding the things which are there.
Here is another good reading will be help you a lot is available at FAQ Tips Tricks Cookbook HowTo
Now the next thing comes in mind is the business process which is really needed to work on, so for this books are available at : http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books/