Architecture Description Registry Web Framework
The framework functionality is accessible from the JSP parts of components through a JSP tag library. This library contains tags for creating references to tasks, nesting components, and tags for creating HTML form elements that support dynamic
behavior.
Sometimes, a component is purely JSP-based as the one associated with this documentation page. But when the page must process user-entered information, or when data must be modified before presentation, you must use the Java part of
the component.
To switch from one page to a another, use the syswf:control custom tag in the JSP part of the source task component. The syswf:control tags targetTask attribute defines the task that is, the page the user should be transferred to. The
custom tag is translated into a piece of JavaScript code responsible for correct page submitting.
Tasks can be accessed directly using a web browser. For example, if the registrys web interface runs on the address http:localhost:8888registryuddiweb
, a task with the URI findBusiness can be accessed directly from the client browser at http:localhost:8888registryuddiwebfindBusiness.
Component Java Interface Part
The Java part of the component must implement the com.systinet.webfw.Component interface from the Web Framework library. However, it usually extends its default implementation: com.systinet.webfw.ComponentImpl. For those
components that do not declare their Java part, this default implementation is automatically used.
The interface consists of two methods: •
void processString action, Map params •
void populateString action, Map params The process method is called just before the translation of the components JSP part is started, so it should take care
of data preparation and it should also handle the actions requested by the user react to pressed buttons, etc.. The populate method is called only when the POST request to the URI comes from the same URI , so its a perfect
place to modify the way data from a web page is populated back into objects. Actually, the target objects are always Java Beans which simplify their handling quite a bit.
Request Diagram
The diagram shown in Figure 12
demonstrates how requests for the page are handled by the Web Framework:
Figure 12. Request Diagram
1. The request is sent by the client browser from a different page than the page requested.
Page 552
Request Diagram
2. The process method is called on taskA components Java part. This method should perform actions triggered by
controls in the web page andor prepare data for taskA components JSP part. 3.
Processing of taskA components JSP part is initialized. 4.
While taskA components JSP part is being processed, the resulting HTML is generated. 5.
Processing of taskA components JSP part finishes; the response is returned to the clients browser.
Note
If the request is sent by the client browser from the same page as the page requested meaning the source and target tasks are the same, then the populate method is called on the task components Java part before the
process method.
Nesting Components
As we noted above, the component JSP part can include other components using the syswf:component custom tag right in the JSP code. The diagram shown in
Figure 13 presents how a request is handled when there are such nested components.
Note that now the request comes from the same task it is targeted to:
Figure 13. Nesting Components Diagram
1. The request is sent by the client browser from the same page as the page requested.
2. The populate method is called on taskA components Java part. This method is responsible for the transfer of
data from web page form elements input fields, radio buttons, etc. to JavaBeans objects on the server. 3.
The process method is called on taskA components Java part. This method should perform actions triggered by controls in the web page andor prepare data for taskA components JSP part.
4. Processing of taskA components JSP part is initialized.
5. Request for insertion of component A is found.
Page 553
Nesting Components
6. The process method is called on the Java part of component A. This method should prepare data for component
presentation. 7.
Processing of the JSP part of component A is performed. Once finished, the result is included in the parent JSP page. 8.
Request for insertion of component B is found. 9.
The process method is called on the Java part of component B. This method should prepare data for component presentation.
10. Processing of the JSP part of component B is performed. Once finished, the result is included in the parent JSP page. 11. Processing of taskA components JSP part finishes. The response is returned in the clients browser.
Component JSP Part
Example 16. Skeleton of the JSP Page
The following example displays the WSDL URL for a WSDL service. taglib prefix=c uri=http:java.sun.comjstlcore
taglib prefix=syswf uri=http:systinet.comjspsyswf syswf:page headerTemplate=pageHeader.jsp footerTemplate=pageFooter.jsp
syswf:wrap headerTemplate=designpageHeader.jsp footerTemplate=designpageFooter.jsp
... syswf:wrap
syswf:page The core of the JSTL standard tag library together with the Registry Web Framework custom tag library are imported.
The beginning of the page is declared syswf:page tag; page header and footer represented as JSP pages are passed as attributes. These pages contain the basic HTML tags and declaration of Java Scripts that will be used in the page.
To enable automatic wrapping and resizing, all of the pages content is packed into the syswf:wrap tag to which page header and footer JSP pages are passed as attributes. The header and footer pages contain:
• The design part - the logo and menu, such as the labels at the top of this page under the product name
• The navigation path - shown in the top right corner of this page
• Text that should be displayed in the bottom of the page, such as copyright information.
Implicit Objects
Implicit objects allow you to interact with various framework parts, from Java code or JSP pages. A reference to an implicit object should be obtained from the com.systinet.uddi.util.CallContext class, or by using simple getter methods
from com.systinet.webfw.ComponentImpl.
• request
HTTP request interface; here you can read, for example, http headers included in users request. Using request attributes is the preferred way to transfer data from Java to JSP pages.
Page 554
Implicit Objects
•
response
HTTP response interface; can be used, for example, to set content type and other response header data or to send binary data back to client.
•
localSession
Contains the java.util.Map object, which is accessible from the current task only. For example, when you have tasks A and B in navigation history, each has a separate local session. When you return from task B
to task A, the whole local session content of task B is discarded. •
globalSession
Contains the java.util.Map object, which is shared among all tasks; this session can be used, for example, to store the current users authToken, or other application-wide data.
Data Types
Data type classes are responsible for converting values between web page HTML form fields and underlying Java Beans objects. The Data type class must implement the simple interface com.systinet.webfw.datatype.DataType with two
methods:
• String objectToWebObject value
provides conversion from arbitrary Java type to String usable in web pages. •
Object webToObjectString value provides conversion in the opposite direction.
There are predefined implementations of this object for converting the simple Java data types string, int, long, and boolean.
Client-side Validators
Validators can be used to validate user input before a web page is submitted to a server. The validation is invoked by a specific page control a button or a link. There is a predefined set of validators for common input field checks.
Table 54. Predefined Validators
Description Name
Checks if the field is not empty. required
Checks if the field content starts with the uddi: prefix. uddiKey
Checks if the field contains no more than the specified number of characters. length50, length80,
length255, length4096, length8192
Checks if the field contains an email address. email
Checks if the field contains a number of type long. long
Checks if the field contains a number of type int. int
To add a validator to an input field or a text area, use the sysfw:checker tag. To trigger the validation control, use the syswf:validate tag.
Example 17. Validators Usage
syswf:input name=businessKey value= syswf:checker name=required action=viewBusinessV3
syswf:checker name=uddiKey action=viewBusinessV3 syswf:input
... syswf:control action=viewBusiness caption=View business mode=button
syswf:validate action=viewBusinessV3 syswf:control
Page 555
Client-side Validators
The Example 17, Validators Usage
shows an input field with two checkers, the first one checks if the field is not empty and the second one checks if the field contains a string starting with the prefix uddi: uddi key. Both checkers are invoked
when a user clicks the View business button.
Validation is performed using a JavaScript function. The validator name is required to be defined in the JavaScript function with the name check_required. The return value from the validator is of the boolean type: true when the field content is
valid, and false when content is invalid. In case of error, the validator displays an error message with the description of the allowed field content. This validator is also responsible for transferring the focus to the field with an error.
Example 18. Required Validator Implementation
is required checker function check_required formID, fieldID
{ var value = getFieldValueformID, fieldID;
if isEmptyvalue {
alertRequired; setFocusformID, fieldID;
return false; }
return true; }
Custom validators should be can be added to the file REGISTRY_HOMEappuddiweb.jarwebrootscriptuddi.js. Many functions for validation are defined in the file REGISTRY_HOMEappuddiweb.jarwebrootscriptwf.js.