THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The request map for the URI main looks like this:
| Code Block |
|---|
<request-map uri="main">
<security https="true" auth="true"/>
<response name="success" type="view" value="main"/>
</request-map>
|
...
The outcome of any processing (which is a string) determines which response to the request is rendered and sent back. In our example, there is only one response to choose from, which is:
| Code Block |
|---|
<response name="success" type="view" value="main"/>
|
...
Let's look at the view-map entry for the view with the name main:
| Code Block |
|---|
<view-map name="main" type="screen" page="component://party/widget/partymgr/PartyScreens.xml#findparty"/>
|
...
The information from the view-map element is resolved against the handlers defined by the elements of type handler, usually in the first section of the controller.xml document. As we are rendering a view, we're only interested in handlers of type "view", so we do a lookup for a handler with type="view" and name="screen":
| Code Block |
|---|
<handler name="screen" type="view" class="org.ofbiz.widget.screen.ScreenWidgetViewHandler"/>
|
The result of the lookup is a Java class - org.ofbiz.widget.screen.ScreenWidgetViewHandler in this case - which extends the AbstractViewHandler class, which implements the ViewHandler inteface interface.
The control servlet will now pass on the processing to the specified view handler by calling the render method using the a, b and c as parameters. It's entirely up to the implementation of the view handler to generate the response and write it to the servlet response channel.
| Panel |
|---|
Hint: So if If you wanted to implement a view handler which is not based on the OFBiz widgets toolkit but using whatever other view technology, as long as it's a servlet based technology, you would have to implement your own ViewHandler class and make it known to the controller servlet by adding a handler element to the controller.xml file. Then you could create one or more view-map elements with the type="yournewhandler" and have any response in a request-map dispatch processing to that view. |
...
- Labels actions
- property-map: to define labels (in a map) from a xml labels file
- property-to-field: to define a field value from a properties file
- Entity actions, this is simple action directly on entities, they are
- entity-and
- entity-condition
- entity-one
- get-related-one
- get-related
- Set actions, mostly 2 "sub-types"
- set : simple assignation
- use of Groovy snippet for a bit more involved assignation (filtered, modified, etc.). Advantage: noe no need to create/open a new file, immediately visible/readable.
- syntax : <set field="fieldName" value="${groovy: 1+1}"/> (you may need to set a type using the type attribute of the set element)
- Script
- script: to call a Groovy script from a file, not short enough to be snippet. Inside your Groovy script you prepare and set your data in a context variable.
- Service
- service: to call a service
...
A decorator literally takes the net content of the screen and decorates is it with everything else which you will see on the screen later. For example, the net content of the findparty screen is just the search form, consisting of some field labels and , fields, and a submit button. But when When the page is rendered in the browser, it needs to have headers, footers, the menu bar, etc. All these elements are added by the decorator.
...
A typical place to look for the definition of the mainDecoratorLocation parameter would be the WEB-INF/web.xml file of the respective webapp, where this parameter can be defined as a context parameter of the web application. In our example (the partymgr app) you will find the following data there:
| Code Block |
|---|
<context-param>
<param-name>mainDecoratorLocation</param-name>
<param-value>component://party/widget/partymgr/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>
|
We can get away with some guesswork about the implementation details of the decorator here, though, to make sure we maintain the bidbird's eye perspective. You can examine the detailed definition of the decorator later. It's just another widget.
...
In case the user has the right to view the findparty form, the actual form content is rendered, controlled by the following XML fragment:
| Code Block |
|---|
<widgets>
<platform-specific>
<html>
<html-template location="component://party/webapp/partymgr/party/findparty.ftl"/>
</html>
</platform-specific>
</widgets>
|
The plaformplatform-specific widget again is a kind of switch-case-statement. The OFBiz widget toolkit isn't limited to rendering HTML user interfaces. It can could theoretically render the user interface in any different technology you can imaging, like Swing, XUML, Flash, speech, ... In case the UI is being rendered in HTML (which is the case most of the time in OFBiz) all widgets which are children of the html element will be rendered.
In this simple example, there is just one widget as a child element of html, which is html-template. That widget uses Freemarker to fill in actual content into a FreeMaker HTML template. The template is pointed to by the component attribute of the html-element widget. The component protocol means that the location of the template is relative to the application.
Stricly Strictly speaking, this is where we leave the OFBiz widget toolkit and you would have to turn to a FreeMaker tutorial to understand the template being used there. Please refer to the FreeMarker Manual.
You may also use the form widget (using <include-form...) instead of a Freemarker template here. There are few more include possibities A form widget is a definition in xml of a list or single form. The form widget is discussed here.
There are few more include possibilities, at all:
- include-menu
- include-form
- include-tree
- include-screen
- include-portal-page
What to display: Data Binding in Forms
Depending of on the tool you will use for final rendering, you will use one of the technic techniques below to bind data to your fields:
...
If you include one or more form widgets, the better way to prepare your data is to use the action part of the screen for the sub element to specify actions specific to the screenform. If This helps if you want to reuse your form elsewhere, or have the actions legible when defining your form, you may prefer to use the action part of the form (we will not detail it here). There, you will also find a . There, you will also find a row-action element to prepare forms of the list type (or multi type, which is variation of the list type). You You may also call a service using the service element. Anyway, there There are plenty of examples of form action actions available OOTB.
Groovy script
...
, which can be found with the following one line script:
| Code Block | ||
|---|---|---|
| ||
find -name "*Forms.xml" -printf '\n\n%p\n\n' -exec sed -n -e '/<actions>/,/<\/actions>/p' {} \; |
Groovy script form action
If you use Freemarker the better way to prepare your form data is to call one or more Groovy scripts. You call them in the action part of the screen. Inside you prepare and set your data in a context variable. There are several examples of Groovy form actions available OOTB, which can be found with the following one line script:
| Code Block | ||
|---|---|---|
| ||
find -name "*Forms.xml" -printf '\n\n%p\n\n' -exec xmllint --xpath "//form//actions//script" {} \; |
| Panel | ||
|---|---|---|
| ||
To continue on screen and form widget, see OFBiz Tutorial - A Beginners Development Guide |