Integrating Pages with Custom Server Logic
1 Writing Java Controllers
2 XGate Servlet
3 Testing and Publishing Applications
4 Creating AJAX Pages
5 Managing Multi-Project Applications
6 Multi lingual Applications
Integrating Pages with Custom Server Logic
This guide will detail the process of integrating your client-side web pages with your custom server logic. This guide provides details of WebMaker's Server Adapter technology, which provides powerful and intuitive data binding capabilities to enable you to map the data between your web pages and Java server controllers. You can use WebMaker's graphical Application Map Feature that enables you to draw the relationships between your web pages and Java server controllers. This guide assumes you have already familiarised yourself with the earlier guide on Designing Web Pages. If you want to use WebMaker's Rules Server to build your server rules, you will find the guide here. When information from pages is submitted, it is received by a server Controller. Which controller receives the information depends on the action that was fired and the application navigation that is defined within the Studio. Within these controllers, you can use the submitted information, perform additional business logic, access databases, call remote services, etc. You can also define how to return any information back to the browser and which page should be used to display the returned information. Application Map Diagram The Application Map diagram can be shown on any Page Design tab by expanding up the panel below the page thumbnails (click the red arrow). Alternatively, you can use the Preferences dialogue to set the diagram to be visible by default. With the Application Map diagram open you can access the controller details tab either by double clicking on a controller, or by using the right-click context menu options. Alternatively there are links in appropriate places within the Bindings and Events tabs that also provide access to the Controller Details tabs. WebMaker enables you to create different server controller types. Each controller type uses a different icon on the Application Map to enable easier identification. If your licence allows, you can adjust the type of a specific Controller by using the Implementation Type options on the right-click context menu.
Receiving calls from other applications on the server
Each Action Link that is painted on the Application Map diagram is available for invocation over HTTP. The action request will be processed, together with any supplied parameters and forwarded to the linked Controller for further processing. The invocations can be via URL, basic HTTP or SOAP.
1 Writing Java Controllers
Java Controllers are identified by the Java icon for the Controller on the WebMaker Application Map diagram. Each Java Controller needs to be implemented in a specific Java Class based on the controller name. WebMaker automatically generates a basic Java file for you which you can then update to include the required functionality. Learn how to integrate your web front-end with a Java server stack
Managing Controller Source Code
You can organise the source code for Java Controllers by using the Java Code File Location and Java Code Package Name entries under the Java Settings section of the Project Properties dialog. All the Java Controller classes within a project must be in the same Java package. Configuring Java Settings
Controller Architecture
Before we start to explore the contents of Java Controllers, it is worth recapping on some of the relevant components within the WebMaker Runtime architecture. The diagram below provides a high-level view of this architecture, focusing on the data bindings and the flow of incoming and outgoing information between client (Browser) and server. mvc_architecture_data_bind_perspective.gif WebMaker provides the ability to bind the data within a web page in two directions. When information is submitted from the browser, an arbitrary XML document structure can be populated with the information contained within the submitted XHTML form. When a page is sent to the browser, another arbitrary XML document structure on the server can be used to bind XML fields to HTML fields on the web page. This bi-directional binding can be performed graphically within the WebMaker Page Design - Bindings tabs. Controllers on the server handle the requests and also compose the response structures that are then transformed by WebMaker to produce the HTML response to the Browser. Java Controllers provide the ability to write Java code to perform the desired tasks on the server. What you do here is dependent on your application scenario, technology standards and architecture. The Java controller class must implement the JavaController interface. This interface defines a processRequest method which should be used to perform all the required processing. The general aim of this method should be to manipulate the incoming data so that it matches the format expected by the next screen. The incoming information submitted from the screen is made available to the Java controller through the RequestData object passed as a parameter to the processRequest method. The information between the client and server is bound for you. Therefore, by the time you receive the information it will be in the structured 'eForm' format that you see within the studio. By default, WebMaker deals with the data in XML format. An example incoming message might therefore look like:
<?xml version="1.0" encoding="UTF-8"?>
<mvc:eForm xmlns="" xmlns:mvc="" xmlns:xg="">
        <Page xmlns="">ContactDetails.xsl</Page>
        <Controller xmlns="">mvc-Contacts-JGetContactsList-Controller</Controller>
        <action xmlns="">getJContactDetails</action>
        <unbound_param xmlns="">value</unbound_param>
        <GetContactRequest Successful="" Version="" xmlns="" xmlns:demo="">
The final response data after the controller has completed processing should be in this same format, and this complete document is transformed to produce the response pages, as defined within WebMaker. Please remember that any submitted elements that failed to bind will be placed under the Control/unbound_param element. Let's now return to an example Java Controller generated by WebMaker:
package com.example.jcontrollers;

import com.hyfinity.utils.RequestIdentification;
import com.hyfinity.xagent.XAgentCallback;

public class Controller_1 implements JavaController

     * Perform any initialisation required for the Java Controller.
     * @param acb Callback interface to access platform services.  Will be null if the full platform is not available.
    public void init(XAgentCallback acb)


     * Main processing method.
     * @param rd This provides all the data for this request.  This should be updated in place as required.
     *           See the RequestDetail docs for details.
     * @param requestId details the session Id and request ID values for the current request.
    public void processRequest(RequestData rd, RequestIdentification requestId)



     * Used to handle any shutdown requirements.
    public void shutdown()


Within each Java Controller, it is the processRequest method that needs to be implemented to perform the required functionality. The rd incoming parameter is the RequestData object providing access to the incoming data. The infomation this contains should be updated accordingly during the processing of the processRequest method.
Controlling Page Flow
The RequestData object provides a simple method (setPageName) for setting which page to display next. As shown above, this method takes in a single parameter specifying the name of the page to display. Once the processRequest method has completed, the page name from the very last call to setPageName will be used to actually render the page and display it to the user. If you wish to know the name of the action that has been invoked to determine which processing to perform, then this can be easily obtained using the RequestData getActionName method.
Accessing the data values
As mentioned above, WebMaker internally processes the data in XML format, and if you are happy with this approach, you can easily get at the data in this way by using the getAsXML method on the RequestData object. This will return an XDocument object which wraps a DOM representation of the XML data and provides some additional helper methods. Alternatively, you can access the incoming data in JSON format by using the getAsJSON method on the RequestData object instead. This will return a JSONObject containing the incoming data. Only one data access method can be used for a given request. To help illustrate how these two approaches can be used, the following fragments provide an example of how you could combine two submitted 'formData' values to produce a third value for later display on screen. XML Approach
XDocument data = rd.getAsXML();
data.addNamespace("mvc", "");
String forename = data.selectString("/mvc:eForm/mvc:Data/mvc:formData/mvc:forename");
String surname = data.selectString("/mvc:eForm/mvc:Data/mvc:formData/mvc:surname");

Element fullNameElem = data.getDocument().createElementNS("", "fullName");
com.hyfinity.utils.xml.DOMUtils.setText(fullNameElem, forename + " " + surname);

JSON Approach
JSONObject data = rd.getAsJSON();

JSONObject fd = (JSONObject) new JSONPointer("/eForm/Data/formData").queryFrom(data);
fd.put("fullName", fd.get("forename") + " " + fd.get("surname"));
Note: Even when using the JSON data format within your Java controller, WebMaker will convert this back to XML data internally in order to perform the transformation that renders the next screen. In certain scenarios, this transformation process may alter the ordering of child elements from the original XML data. If this occurrs, it is unlikely to cause any issues, but you can always fall back to the getAsXML approach instead.
Compiling and Running Java Controllers
You can use the in-built WebMaker Editor or a Java Development tool of your choice to author and compile the Java classes for each controller. WebMaker will autoamtically create a sample Apache Ant build.xml file for compiling the code, but you are free to use whatever tool suits your workflow. You will need to ensure that the WebMaker xplatform.jar file is on your classpath for the code to compile successfully. This jar is located within the {Install Location}\design\tomcat-design\lib directory of a standard WebMaker installation. The easiest way to ensure your classes are picked up when testing or publishing the project is to place the compiled code within the webapp directory for the project. eg {Install Location}\users\{user name}\{workspace name}\mvc\{project name}\webapp\WEB-INF\classes\lib. If you use the default code location and the generated build script then this will happen automatically. This compiled code will then be included correctly when you use the Run Test or Publish actions in the WebMaker Studio. You can use the Debugger to check execution details via the View Debugger tab. This will also show details of any errors, including the inability to locate the controller or inability to execute the controller, etc. You may need to adjust the Platform Log Level to debug in the Test Settings or Publication Settings dialogs as appropriate to make sure you are getting all available information logged to help resolve any errors. Important: If you are using a runtime environment that runs multiple applications within one Java webapp (such as the default BizFlow WebMaker publication) then the compiled code will not be automatically picked up as above, and you will instead need to manually ensure the code can be loaded by the application server in use.
Note: Previous versions of WebMaker supported a more restrictive form of Java Controllers based around a JController base class. This format is now deprecated. Any existing implementations will continue to function for now, but the new approach described above should be used going forward.
2 XGate Servlet
XGate is a WebMaker server component that handles requests from the browser, performs data-bindings and forwards requests to server controllers. XGate also sends responses back to the browser. In both directions, XGate has the ability to use plug-ins to intercept and alter behaviour based on your custom code. XGate can also act as a gateway to remote service invocations, including calls to SOAP and REST services. (Requires XML Controllers).
XGate Configuration
The XGate configuration details reside in the deployment descriptor file of the Web application. If {webapps_location} is the web application deployment area of the Web server, the XML deployment descriptor of a {myapp} application can be found under {webapps_location}/{myapp}/WEB-INF/web.xml. An example web.xml file is shown below:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
            <!-- Sets the Morphyc configuration file to use for this application -->
        <!-- Set all incoming requests to be handled by XGate.
             For an MVC application the mapping would be '*.do' to not pick up CSS, image, etc requests-->

XGate also accepts a second configuration file stored in {webapps_location}/{myapp}/doc/xgate.xml. If this file is not present, a version will be generated the first time a Run Test or Publish operation is performed. If defined, this file can be accessed via the Include Local File options on the Files tab of Page Design, and then navigating to the relevant location. An example of this configuration file is below.
<?xml version="1.0" encoding="UTF-8"?>
<xgate xmlns:xg="" xmlns:xfact="">
        <!--Turn on SXForms processing for binding HTTP Parameters into XML structure -->
        <sxforms mark_unbound="true" delete_bound="true">true</sxforms>
        <!--Ensure HTML output is returned to the browser -->
        <!--Output the HTML 5 Doctype-->
        <output_doctype doctype_system="" doctype_public="">true</output_doctype>
        <!-- disable pre processing of soap requests.
             If this is enabled, then a transform can be applied to incoming SOAP requests to format them for
             processing as standard HTML parameter based requests.-->
        <!-- If true, automatically set the Language control field based on the user's locale -->
        <!-- If set to true, this enables the cookie handling functionality -->
        <!-- Enables file upload support for this application. The two attributes are optional, and not provided by default.-->
        <file_upload upload_dir="c:\temp\uploads" plugin_class="com.example.MyFileUploadPlugin">true</file_upload>

        <!-- Define any custom plug-ins required -->
            <custom_plugin name="My Plug-in" runtime_instance="com.test.MyPlugin" priority="10"/>
This file provides control over a number of in-built features and the ability to define your own custom plug-ins. These plug-ins reside between the browser and server and allow interception and inspection of the data received from the browser, and the response being sent back to the browser. For example, a plug-in could be used to enforce custom security checks before allowing access to the controllers. See the next section for more details on writing custom plug-ins. Both of these configuration files are automatically set up when applications are published from the WebMaker Studio. You can change these files and place copies within the relevant locations under the webapp directory for your project in the repository. This ensures your changed files will be reused for future test and publish operations. XGate also makes use of other configuration files that are located within the doc directory within particular webapp structures, but these files should be managed automatically by the WebMaker Studio. You can learn more about XGate plug-ins on the WebMaker Forum. Search for "xgate".
Cookie Processing
If the process_cookies setting in the xgate.xml configuration file is set to true, XGate will perform some automatic handling of browser cookies. Firstly it will provide a list of all of the cookies received from the client in the Control section of the message so that they can be easily accessed from your Controllers.
<eForm xmlns="">
            <Cookie name="JSESSIONID" value="61EF3E000F8A491327BA7DEE7258FE66"/>
            <Cookie name="mycookie" value="cookievalue"/>
Secondly, before returning the response to the client, any changes to ths Cookies fragment will be detected and processed. If the value attribute for a cookie has been updated, this new value will be sent to the browser. If a Cookie element is removed completely, then the cookie will also be removed from the browser. If a new Cookie element is inserted into this Control fragment, then the browser will be sent the new cookie. When creating a new cookie, there are a number of extra attributes that can be used if required to further configure the new cookie:
<Cookie name="NewCookie" value="123" comment="cookie comment" domain="" path="/myapp" maxAge="1800" secure="true" httpOnly="true" xmlns="" /> 
Adding Custom Plug-ins
Custom plug-ins allow you to write your own Java code to augment the standard functionality provided by the XGate Servlet. Each custom plug-in needs to implement the com.hyfinity.xgate.XGatePlugin interface, the JavaDoc for which is available here. This interface defines two methods that require implementation, processInput and processOutput. The first will be called on each incoming request to give you the option to manipulate the request before it is passed to server controllers for processing, whereas the second will be called with the response received from server controllers (usually HTML content) to perform any final manipulation before the response is returned to the browser. You can define as many custom plug-ins as you need by listing each one as a custom_plugin element in the xgate.xml file as shown below.
        <custom_plugin name="my plug-in" priority="10" runtime_instance=""/>
        <custom_plugin name="custom plug-in 2" priority="70" runtime_instance=""/>
The name attribute provides a friendly name for the plug-in that is output to the Debugger logs, the runtime_instance attribute provides the classname for your plug-in, and the priority configures the order in which the plug-ins will execute. Plug-ins with a lower priority number will be called first. All the in-built plug-ins that handle the data binding process, etc., have a fixed priority of 50. Therefore, if you add your custom plug-in with a priority less that this, the message it receives will generally be a flat list of parameters sent from the browser, whereas if you use a priority value over 50, the message will look like the structured XML you see in the various binding screens. If you need to return non-HTML content (e.g. to return a PDF file), you can do this from the processOutput method. You need to output your content to the response object directly, and then set the output document to null (output.setDocument(null)) to prevent XGate from attempting to return the normal content. Once you have written your plug-in you will need to ensure it is compiled successfully and available to your deployed/published application. One way to do this is to place your compiled classes/jar within the WEB-INF directory under the webapp directory for your project in the repository. All the jars needed to compile your code can be found in the <install_dir>/design/tomcat-design/common/lib directory. When you are trying to debug custom plug-ins, it is useful to switch the logging level to debug via the Test Settings menu option. You will then be able use the Debugger to see the state of the message before and after calling each plug-in. This is normally suppressed for applications during development.
3 Testing and Publishing Applications
Details on Previewing and Exporting pages were covered earlier. In this section we will provide additional details on the features that are available for testing and publishing your applications.
Testing Pages
When you are happy with the look-and-feel of your pages within the Preview, you can use the Run Test button on the Toolbar (or Test | Run Test menu entry) to run your complete application on the local test environment. This will open up a new tab, initially showing the 'start' page in your project. At this point you are now viewing the pages within a running application, including the application of all dynamic settings. Therefore, you can now test the navigation between pages, etc. Previewing Pages When testing your projects in this way, you can use the Debugger to obtain more information about your running application. Once you are happy that the project is working correctly, the Publish functionality can be used to package your application for installation on production environments. You can locate more comprehensive information on testing, publishing, debugging, configuring and monitoring your applications within different server environments, later in this documentation.
For additional details on testing, debugging and publishing your applications, please see the following sections:
Testing and debugging applications and configuring test environments Publishing applications and configuring runtime server environments Managing runtime server environments and using the Debugger to monitor, debug and optimise applications
Learn how to publish an application to a WebMaker Server on DigitalOcean
4 Creating AJAX Pages
You can create pages that make asynchronous calls to server Controllers, refreshing only parts of a full page. In order to achieve this, you need to add a partial page, which will provide the asynchronously updated page content. Once the Application Map has been displayed (expand it up on any Page Design tab) you can add a new Partial Page using the icons on the left side palette. There are two partial page icons for the different server implementation types available (see below for details). The implementation type for an existing partial page can be easily changed if needed using the right-click context menu options. The design of partial pages is very similar to normal page design, whereby you can access server controller functionality, perform automatic bindings and also use schema-driven data sources to accelerate page design. Creating Ajax Pages
Some of the key differences between full and partial pages include:
In almost all cases, partial pages will be linked to from full pages. The partial pages represent a part of the full page. Each partial page has an integrated server controller because a partial page generally requires a call to something (database, web service, etc) to enable a refresh of the part of the full page that it is dealing with. You can access the controller details from the right-click context menu for the Partial Page on the Application Map diagram. A Partial Page can contain either a Java controller or an XML Rules controller. The development process for the server component of a Partial Page is the same as that for a standalone server controller. You may notice that the partial page previews do not show the main page that they are called from. They simply show the partial page content. In order to make an asynchronous call to the server from a partial page, you have to use the AJAX submission option within the Events tab of the Page Design screen. Against this submission type, you will notice the need to provide a Target Group as well as a Source Type. The target group represents the area of the screen that will be refreshed with the response from the server. You should ensure that you have a suitable container group to receive the response of the AJAX Submission. The palette contains some default containers that have been preconfigured e.g. Partial Page Container. You will also notice a Source Type option. This allows you to submit a part of the full page as the request data, or the full page if this is more appropriate depending on the data required by the Partial Page.
5 Managing Multi-Project Applications
WebMaker allows you to decompose large applications into multiple projects. This provides a more manageable application specification and can aid better understanding during development and maintenance. This section details the options available to integrate these multiple projects to produce a single application. Each project within WebMaker has its own set of assets and can communicate with other projects.
There are scenarios when two or more projects may wish to 'communicate' with each other. These scenarios typically fall into two categories:
Call Remote Page - A screen in one project contains a button (or other event) that shows a screen from another project. Call Remote Controller - A controller in one project wishes to call a controller in another project.
Important Note: A key requirement for integrating multiple projects is that all the action names (Action links on the Application Map) used across your projects must be unique. One way to achieve this is to simply add a project-specific prefix to the action names for example.
Considerations for Test Settings
Blueprint Specification part - The Test Settings screen (representing the underlying Morphyc.xml file) represents the control file for an application and lists all projects within the same application context. Multiple projects can be configured to save their deployment configuration information into the same morphyc file. Assuming one of the projects acts as the master/parent project, this can be done by selecting the Test Settings - Location Details from the menu for a 'child' project, and updating the value for the Test Settings File Location and the Test Web Server Location to the values from the 'parent' project, before hitting the Save button. To populate the changed settings for the 'child' project into the 'parent' project, you need to perform a Run Test to setup the necessary runtime test environment details. This needs to be repeated for each 'child' project to ensure they are successfully referenced in the same morphyc configuration file in the 'parent' project. This is a one off process. Once the correct entries has been placed in the required morphyc file via Test Settings, they will be maintained in future.
Call Remote Page
Once the Test Settings steps have been completed, the running 'parent' project should contain all the included projects, and it becomes possible to make calls between pages in different project as if they were in the same project. To check the setup, go to the Test Settings screen for the 'parent' project and view the Projects in this Environment. You should see the 'parent' project and all the 'child' projects that are referenced. You can then use the Action name that you want to call (in the target project) as the URL that is called from the source page, whether this be through form or ajax submission or just a standard anchor link. WebMaker currently does not list the actions of a second project using the Form Submission action type within the Page Design screen. Instead, you should select the Enter action name option and then type in the action name manually.
Call Remote Controller
In order to achieve the second type of project interaction, you need to create what is known as an Inter-Project Proxy. These are controllers that work in a very similar way to Web Service Proxies, but rather than representing remote external service URLs, inter-project proxies are used to represent a controller in another project. In the (source) project that wishes to call the controller in the second (target) project you need to create an 'empty' controller, which will act as the proxy to the real controller within the target project. As far as the first project is concerned, this new 'empty' controller will appear the real controller in the second project, and can be called directly as required. At runtime, any calls to Inter-Project Proxy controllers will actually be handled by the real controller in the second project. In order to achieve this, the 'empty' (no rules processing) Proxy Controller needs to be set-up correctly. This can be achieved by opening the Project Settings tab and clicking on the Runtime Patterns tab. Typically, click on the Model layer to set-up a Remote Proxy Controller. Type in the New Filename for the reference to the Controller you want to call e.g. {RemoteControllerName_Proxy} and click on the Clone Pattern button. This will display a further screen that allows you to select the Base Pattern to be used - In this case the Remote_Service_Proxy.xml file. Finally, click on the Clone Pattern button to create the Controller. Once this is done, open the Test Settings and select the Agent Types menu option. Click on the Agent Id for the Controller just created, and then change its Agent Type to the Inter Project Proxy option and enter the Target Agent Id as the full Agent Id of the Controller in the target project. This will appear something like mvc-{project}-{pattern}-{agent}. Note: This value can be seen in the Debugger logs of the 'target' project. Finally, Click on the Change Agent Type to commit the change.
Inter-Project Proxies versus Web Service Proxies
Please Note: Use of Inter Project proxies requires that the deployment settings mentioned above are completed to ensure both projects are running within the same application server and in the same Java Virtual Machine (JVM). If you need to communicate between projects that are running on different machines, then you should deploy the 'empty' controller as a Web Service Proxy using the http service option, and the target controller should be deployed as a Web Service. This will allow you to treat the proxy controller as if it was the Agent in the target project and call it directly, even though in reality it is deployed to a separate machine and will be accessed via HTTP.
Rendering Pages in Remote Projects
The details above explained how you can call an action in another project by adjusting the event definition for the relevant trigger button. This works fine when you know at design time that you will always be navigating to another project, but what about the situation where you need to decide on the server which page (from multiple projects) to render? When you are dealing with a single project, you can make these decisions on the server by changing the value of the Page control field in the bindings message structure. But when you want to render a page in a second project it is a bit more complicated. To do this, you will need to create an inter-project proxy to the 'view' controller of the 'target' project. Then, when you need to render the page from the second project, you need to adjust the Page control value, and then call this view proxy to tell the target project to render the correct page. It is important to note however that when this is done, the HTML information returned from the target 'view' controller will still flow back through the controller in the 'controller' and 'view' layers of the current project before being returned to the browser. The rules within the local controller may need to be adjusted to alter the data structure if required.
Binding Considerations When Calling Pages in Remote Projects
You are able to provide different binding structures for each action submission from a page. A WebMaker Project does not know about actions you may wish to call in external projects. You will therefore not see actions in such external projects within the Bindings tab. As a result, actions to external projects will simply submit data that will have no bindings and resort the default binding structure, ending up in the Control section of the bindings document, instead of the formData section. The best approach to ensure your submission data is structured, even when such data is submitted to remote projects, is to set the required bindings structure for one of the actions. Then set the Set bindings and structure based on another action? option in the Advanced Bindings Mode section for ALL other actions and use the settings for the base action defined earlier. This triggers WebMaker to use the same binding structure for all actions, even for actions it does not know about, such as those being called in remote projects.
6 Multi lingual Applications
You can add translations for your WebMaker applications after development. This can be achieved by creating translation files, which map information on web pages to their translations in the required language and locale. Before rendering pages WebMaker attempts to locate translation files for locales. If translation files for specific locales are not present, WebMaker then attempts to access general translation files for the language (e.g. if the en-GB translation file is not available, then WebMaker will seek to process file en). If no translation files are present at all, then WebMaker will use the original language used during development. To use translations, the first step is to create a web application based on one of the languages you need to support. This should ideally be the most commonly used language. Then add language and locale specific XML translation files for each language. You can apply translations to elements, including labels, captions, tool-tips, drop-down list options, etc. The translation files, which we also refer to as dictionary files, are written in XML. An example is shown in the listing below:
<translations xmlns="" language_code="en" direction="ltr">
		<translation_item id="username" action="replace">
		    <part type="label" value="translated username label"/>
	<page id="NewForm">
		<translation_item id="title" action="replace">
			 <part type="label" value="translated title label"/>
			 <part type="field_tip" value="Translated field tip"/>
			 <part type="custom_attribute" data_value="currency" value="EUR" />
		<translation_item id="submit_button" action="replace">
			<part type="caption" value="translated caption"/>
		<translation_item id="output_field" action="replace">
			<part type="caption" value="translated output value"/>
		<translation_item id="radio_1" action="replace" >
		    <part type="label" value="This is a question?" />
			<part type="select_option" data_value="Y" value="Yes" />
			<part type="select_option" data_value="N" value="No" />
		<translation_item id="select_box" action="replace">
			<part type="select_option" dynamic_value="Value1" value="Translated Value1"/>
			<part type="select_option" dynamic_value="Value2" value="Translated Value2"/>
		<translation_item id="date_2" action="replace">
			<part type="date_format" dynamic_value="MM/dd/yyyy" value="dd-MM-yyyy" />
		<translation_item id="tab_control" action="replace">
			<part type="select_option" data_value="tab1" value="Translated Tab 1" />
			<part type="select_option" data_value="tab2" value="Translated Tab 2" />
		<translation_item id="show_hide_details" action="replace">
			<part type="caption" value="translated Section Details"/>
			<part type="custom_attribute" data_value="showLabel" value="translated Show"/>
			<part type="custom_attribute" data_value="hideLabel" value="translated Hide"/>
		<translation_item id="accordion_pane2" action="replace">
			<part type="custom_attribute" data_value="title" value="translated Pane 2" />
		<translation_item id="paragraph_1" action="replace">
			<part type="paragraph">
		        <p>Replacing some paragraph text including HTML embedded content.</p>
The root element of the translations file is translations, which has two attributes, the language_code and the direction. The direction attribute can be ltr (Left-To-Right) or rtl (Right-To-Left). The default is ltr and rtl is used for languages such as Arabic. The global section defines translations to be used throughout the application, applicable to all pages. This is followed by a number of page sections, one for each page that contains elements requiring translations. Each translatable field is identified by a translation_item element, whose id attribute must match the field or group name as defined in the WebMaker Studio. For each field, a number of options can be translated if required, by specifying part tags. As shown in the example above, the type attribute indicates what kind of string is being translated (the field's label for example) and the value attribute contains the translated string to use. To translate a set of radio buttons or select box options, set the type attribute to select_option and the data_value attribute to identify the data value the translation applies to. You can then specify your translation for this part in the value attribute. For example:
For English:
 <part type="select_option" data_value="G" value="Green"/>
 <part type="select_option" data_value="B" value="Blue"/>

For Russian:
 <part type="select_option" data_value="G" value="зеленый"/>
 <part type="select_option" data_value="B" value="синий"/> 
You need to create one dictionary file for each language you wish to support in your application. The files need to be named in the format dictionary_[language code].xml. For example, to support English, French and Spanish, you would need the following three dictionary files: dictionary_en.xml, dictionary_fr.xml, and dictionary_es.xml. If you are using locale values then the filenames would be dictionary_[language code]-[locale].xml. For example, English-British would be: dictionary_en-GB.xml Table : List of items that can be translated, where you can locate them in the WebMaker Studio, and the XML definitions that should be used.
Control Attributes on the Properties Panel Part Type Translation Details
Label label <part type="label" value="translated title label"/>
Data Constraints - Options(Enumerations). Applies to Radio, MultiCheckbox, Select Box (DropDown List) select_option <part type="select_option" data_value="Y" value="Yes" />

Note: You need one part for each option that needs to be translated. You can use either the data_value or dynamic_value attribute as appropriate to indicate which entry to translate. If data_value is used this will be compared to the underlying value in the data, whereas dynamic_value will be compared to the string that would otherwise be displayed. These map to the DataValue and Display Text options shown on the General Properties tab for the control.
Accessibility Options - Field Tip (Generally applicable for almost all Controls) field_tip <part type="field_tip" value="Translated field tip"/>
Custom Attributes (Generally applicable for almost all Controls) custom_attribute <part type="custom_attribute" data_value="title" value="translated Pane 2" />

Note: The data_value is the name of the custom_attribute. There can be multiple custom_attributes.
Button and Anchor Controls - Caption caption <part type="caption" value="translated submit button"/>
Display Only Control caption <part type="caption" value="translated output value"/>

If your output field can display a dynamic set of values (e.g. status values), then add the dynamic_value attribute. E.g.

<part type="caption" dynamic_value="Active" value="Active Translation"/> <part type="caption" dynamic_value="Complete" value="Complete Translation"/>
Currency Amount custom_attribute <part type="custom_attribute" data_value="currency" value="EUR" />
Value Conversions - Dates - Display format date_format <part type="date_format" dynamic_value="MM/dd/yyyy" value="dd-MMyyyy" />

Note: The dynamic_value relates to the base forms Display Date format. The value is the required format for the language.
Tabs - Tab control field select_option <part type="select_option" data_value="tab2" value="Translated Tab 2" />

Notes: Tabs use the Data Constraints for the definition of the Tab names.
Accordion - Bar titles defined as a custom attribute custom_attribute <part type="custom_attribute" data_value="title" value="translated Pane 2" />
Collapsible Section - toggle button caption custom_attribute <translation_item action="replace" id="show_hide_details"> <part type="caption" value="translated Section Details"/> <part type="custom_attribute" data_value="showLabel" value="translated Show"/> <part type="custom_attribute" data_value="hideLabel" value="translated Hide"/> </translation_item>
Paragraph paragraph <part type="paragraph"><p>Replacing some paragraph text including HTML embedded content.</p></part>

Note: The paragraph contains the HTML content of the rich text paragraph editor.
Repeats, e.g. Tables repeat_no_data <part type="repeat_no_data" value="translated No data available for display"/>
Display Variables with default values display_variables <translation_item action="replace" id="display_variables"> <part type="var1" value="translated Display Variable value"/> <part type="var2" value="translated Display Variable value"/> </translation_item>
Error Message Override error_message <part type="error_message" value="translated Error Display message"/>
Default Error Messages default_error_messages <translation_item action="replace" id="default_error_messages"> <part type="1" value="translated Invalid Type"/> <part type="2" value="translated This Field Is Required"/> <part type="3" value="translated Missing number"/> </translation_item>

See validationError.js for a complete listing of type values.
Placeholder Text placeholder <part type="placeholder" value="translated Placeholder Text"/>
Hints hint <part type="hint" value="translated Hint Text"></part> <part type="hint"><b>Replacing some hint text including HTML embedded content.</b></part>

Note: The second part in the above example allows for HTML content rather than just static translated text.
Menu Controls select_option hint Use select_option part types to translate the displayed text for each menu item, in the same way as for select box/radio button controls. This will work for static menu options configured on the General Properties tab, as well as for more complex mult level menus created using the dynamic option.
In addition, you can add matching hint type part entries to translate any hint messages provided through the dynamic menu configuration structure.

<translation_item id="menu" action="replace"> <part type="select_option" data_value="about" value="Translated About"/> <part type="select_option" dynamic_value="Products" value="Translated Products"/> <part type="hint" data_value="about" value="Translated About Hint Message"/> <part type="hint" dynamic_value="Products" value="Translated Products Hint Message"/> </translation_item>

Once you have created your dictionary files, you need to include them as resource files within WebMaker, to enable WebMaker to access them dynamically at runtime. You can include your translation files using the following steps: 1. Select Project | Advanced Project Settings... 2. Select the Assets tab. 3. Click the Other Resources folder on the Server Repository panel. 4. Now you can upload your translation files using the Upload Local File section. Translations File 5. Once you have uploaded your files to the repository, you need to let the WebMaker Page Painter know that these files need to be used during runtime execution to translate your pages. To do this: 6. Click the views link within Runtime Patterns. 7. Now click the view link in the views list. 8. Select the View Node Details radio option for Double Click Action and then double-click on the Page_Painter view icon. Translation Node Details Now click the View Engine & Resource Details link. You should see a screen as shown below. 9. Select the Other Resources of your project from the Available Resource Categories list under the Resource Details section. Translations File as a Resource 10. You should now be able to include your translation files from the Resources in Category dropdown. You should be able to select and add each of your files using the Add Resource button. As you add each file, they should appear under the Current Resources section. 11. When you have finished adding all your files, you can click Save. You can test your translations using a parameterised approach (http://localhost:7080/Example/ You can also configure your application to automatically recognise the user's locale setting. To enable the automatic option, you need to ensure the set_locale element is set to true in the xgate.xml configuration file. If you do not yet have this file in your project repository, then create a new directory called doc under the existing webapp folder for your project, (e.g. [Install Location]/users/user[number]/[workspace]]/mvc/[project]]/webapp). You can now copy the default xgate.xml file from the deployed project location (e.g. [Install Location]\runtime\tomcat-runtime\webapps\[project]\doc\xgate.xml) into this new directory. Copying this file to your repository makes sure that any changes you make to the file will be used for all future deploy and publish operations. You can verify your translations setup by using the Debugger. Simply check the Language value in the Control block of the messages.