Interleaving the XForms processing model with java server faces request processing

1. Field of the Invention

The present invention relates to forms processing and more particularly to XForms forms processing.

2. Description of the Related Art

Form based input is the enabling technology which permits the widespread distribution of applications across generic client platforms such as the conventional content browser. In the prototypical distributed application, a markup language defined interface can form the principal conduit through which end users can interact with backend application logic. Often configured in the form of a Web page, the interface can be provided to the content browser by a content server and can take the form either of a pre-defined static page, or a dynamically generated page. Form input fields can be positioned within the interface through which user input can be accepted and posted to the backend application logic for further processing.

Despite the flexibility afforded by hypertext markup language (HTML) defined forms, HTML defined forms mix data, logic and presentation in contravention of standard programming practices. In this regard, the well-known model-view-controller paradigm demands that each of data, logic presentation remain separable. In this way, though the presentation layer may change to suit the user interface requirements of an end user, the underlying logic layer need not also change. To accommodate the increasing complexity of transactions conducted through forms, the XForms specification has been proposed as a presentation independent way of handling interactive Web transactions. Significantly, the XForms specification separates data and logic from presentation in that XForms utilizes the extensible markup language (XML) for data transport and HTML for data display.

Forms technologies are typically bound directly to a presentation specification such as the XHTML specification, the portable document format (PDF) specification and the like. Yet, currently, there is no way to integrate XForms with the Java 2 Platform, Enterprise Edition (J2EE) programming model as interactive J2EE applications assume a server side processing model often complimented with a robust MVC application framework. One such framework is the Java Server Faces (JSF) framework. Designed to be flexible, JSF leverages existing, standard user interface and web-tier concepts without limiting developers to a particular mark-up language, protocol, or client device.

The user interface component classes included with JSF encapsulate the component functionality, not the client-specific presentation, thus enabling JSF user interface components to be rendered to various client devices. By combining the user interface component functionality with customized renderers, which define rendering attributes for a specific user interface component, developers can construct custom tags to a particular client device. As a convenience, JSF provides a custom renderer and a JSP custom tag library for rendering to an HTML client, allowing developers of J2EE applications to use JSF technology in their applications.

Embodiments of the present invention address deficiencies of the art in respect to forms processing for Web applications and provide a novel and non-obvious method, system and apparatus for interleaving XForms and JSF processing. In this regard, embodiments of the present invention provide for a declarative and non-intrusive integration of XForms and J2EE in order to achieve a rich forms processing engine. Specifically, a common form processing engine component can be provided which implements the XForms event model during the JSF processing lifecycle. As a result, Web application developers can seamlessly integrate robust forms processing into J2EE applications.

In an embodiment of the invention, a data processing system for interleaving XForms with JSF request processing can be provided. The system can include an XForms definition generated for a form configured for rendering in a Web application. Specifically, the XForms definition can specify a data model for data to be processed within the form. The system further can include a JSF code generation module programmed to process the forms model to produce a form bean, a faces configuration, and a JSF page for each navigable view defined in the XForms definition.

Optionally, the XForms definition also can include one or more bindings for data used by controls within the form with fields of the data model. Also, the XForms definition further can include statements linking actions in the form with corresponding command invocations. In another optional configuration, the form bean can include getter and setter methods for a plurality of bound elements disposed in the form. Likewise, the faces configuration can specify the form bean. Additionally, the faces configuration can include a lifecycle phase listener for forms processor integration. Moreover, the faces configuration can include navigational rules based upon navigation groups in the XForms definition. Finally, each JSF page can include a server page generated for each of the navigation groups.

In another embodiment of the invention, a method for interleaving XForms with JSF request processing can be provided. The method can include rendering a JSF request to generate a forms context for a form, registering a forms processor as a validator for at least one control in the form which has been bound to data for the form and accepting data for the form and applying control data for the accepted data. The validator can be called to perform validations on the control data for the accepted data. Subsequently, the accepted data can be applied to a model instance inside the form. In another aspect of the invention, an event can be dispatched to the forms processor through a form bean responsive to detecting an event which generates request processing. For instance, the method can include re-querying instance data and control properties through the form bean.

Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein:

FIG. 1 is a schematic illustration of a data processing system for interleaving XForms with JSF request processing; and,

FIG. 2 is a flow chart illustrating a process for interleaving XForms with JSF request processing.

Embodiments of the present invention provide a method, system and computer program product for interleaving XForms with JSF request processing. In accordance with an embodiment of the present invention, an XForms definition can be generated for a form to be rendered for a Web application. The XForms definition can specify a data model for data to be processed within the form and a name space for the data. The XForms definition further can bind statements for data used by controls within the form with the fields of the data model. Finally, the XForms definition can link actions in the form to command invocations.

A JSF code generation module can process the forms model to produce a form bean, a faces configuration and a multiplicity of JSF pages. The form bean can include getter and setter methods for every binding element, arbitrary data, control properties, event handler and submission in the form. The faces configuration file, in turn, can declare the managed bean for the form, a lifecycle phase listener for forms processor integration and navigational rules based upon navigation groups in the form definition. Finally, each JSF page can be a server page generated for each navigation group defined in the form. The server page can specify the initialization of the forms context and the location of the form definition, the binding of each control and its corresponding control properties in the form to the form bean, and action handlers for controls in the form with methods in the form bean.

In further illustration, FIG. 1 is a schematic illustration of a data processing system for interleaving XForms with JSF request processing. The system can include a forms builder 110 configured to generate both a forms model 120 and an internal tools user interface model 130 . The forms model 120 and the internal tools user interface model 130 can be combined in a single document which can include a forms definition including the specification of one or more name spaces and a data structure for the data to be processed within the form.

The forms model 120 also can include a specification of a command to be invoked for an instance of a portal processing a form based upon the forms model 120 . The forms model 120 further can include a specification of a binding for data used by controls within a form based upon the forms model 120 . The forms model 120 yet further can include a specification of a submission definition used by an XForms processor to invoke a command and corresponding result logic. Finally, the forms model 120 can include a binding of user interface groupings to actions and action parameters.

An exemplary forms model 120 follows:

The system can include a JSF code generation module 140 . The JSF code generation module 140 can be programmed to process the forms model 120 and the internal tools user interface model 130 to produce each of a form bean 150 , a faces configuration 160 and one or more JSF pages 170 . The form bean 150 can include getter and setter methods for every binding element, arbitrary data, control properties, event handler and submission in the form. In this regard, the control properties can be an interface having the methods boolean is Relevent( ), boolean is ReadOnly( ), and boolean is Required( ) which are properties that may change as the form performs its processing.

An exemplary form bean follows:

The faces configuration 160 can declare the managed bean for the form, a lifecycle phase listener for forms processor integration and navigational rules based upon navigation groups in the form definition. In particular, the responsibility for linking JSF request processing with the forms event processing rests on the lifecycle phase listener. The lifecycle phase listener can prepare the forms processing engine for each phase and the life cycle phase listener can initiate events and processing on the forms side. An exemplary faces configuration file 160 follows:

Finally, each of the JSF pages 170 can be a server page generated for each navigation group defined in the form. Specifically, the server page can specify the initialization of the forms context and the location of the form definition, the binding of each control and its corresponding control properties in the form to the form bean, and action handlers for controls in the form with methods in the form bean. An exemplary fragment from a JSF pages 170 follows:

In more particular illustration, FIG. 2 is a flow chart illustrating a process for interleaving XForms with JSF request processing. Beginning in block 210 , a non-faces request can be rendered with a JSF server page containing an “initForm” tag resulting in the creation of a forms context. Every following request will have a forms context associated with it. In block 220 , the view having been rendered and the view root having become available from the forms context, the lifecycle phase listener can register the forms processor as a validator on any controls bound to forms data. Subsequently, the forms processor can be set to accept control data to prepare for a validations phase and data can be applied to forms control data from any controls that are bound to form data.

In block 230 , since the forms processor will have been registered as a validator for controls bound to it, the validator can be called to perform validations on control data. Messages can be generated appropriately and controls can be marked as valid or invalid. In block 240 , the form control data will have been validated and values from controls can be applied to the model instance inside the form. In block 250 , any event which generates request processing can be dispatched to the forms processor via the form bean. Finally, in block 260 , form instance data and control properties can be re-queried during this phase via the form bean.

Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, and the like. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.

For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, or semiconductor system (or apparatus or device). Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.