Message Properties / JSS

The first part of building any UI layer is to define a configurable message store to enable configurable display strings external from the codebase. GI is no exception in this regard. JSXAPPS/gi2spring/jss/messages.jss defines a level of indirection for messages. JSS is short for JavaScript Style Sheets. This is a convention unique to GI that encapsulates concepts of CSS for dynamic styling, but extend the concept to any property of any object - not just the visual ones. In the same way a jsp author would code "" the GI Builder allows the designer to define widget content by selecting from a drop down.





Automated creation of JSS

For convenience we developed a command line ant task tool to perform this conversion look for Properties2Jss.java under src\tools\java.

After applying Properties2Jss this becomes:



Mapping Rule Service

Next step in construction is to handle the messages created by the XMLView to and from the server. GI provides a high level service (jsx3.net.Service) for you to extend.

The GI Service has several responsibilities:

    •     Marshalling UI screen component content to a request message
    •     Sending that request to the server
    •     Un-marshalling the response message to UI components
    •     Calling user provided event handlers (success, error, timeout)

The Service interprets a set of message transformation and object binding rules stored in a rules/*.rule file. These rule files are created with the XML Mapping Utility, a rule editor within GI Builder. Rules files enable message formats, urls, data, and UI mappings to change independently of the JavaScript controller that orchestrates them.

In order to use the rule editor we save a copy of the server output in JSXAPPS/gi2spring/xml as displayprices.xml. Next, we'll need to create a XML mapping rule for each of the three flows coming from the server (price list, price increase and error).
Creating the Mapping Rule

Our application is not a SOAP Web service so we choose XML/XHTML/Schema rule type. Our Spring process will be invoked using a GET action with a standard URL. Therefore there is no outbound document we'll pass to Spring. Our inbound document is pointed at our sample document. Placing the Mapper Log into trace level gives us additional insight into the process.