WO2002037311A2 - Presentation layer for business application development and methods thereof - Google Patents

Abstract

A presentation layer is provided that makes application development and customization easier and more efficient by reducing the amount of specialized code written for a specific application. A set of standard display objects is offered to the application developer. Customization parameters (i.e., look and feel) are specified in filter and configuration files using a defined XML specification. The presentation layer handles the mapping of business object values into and out of (User Interface) UI elements using the configuration and filter files.

Description

T I TL E

PRESENTATION LAYER FOR BUSINESS APPLICATION DEVELOPMENT

AND METHODS THEREOF

RELATION TO PRIOR APPLICATIONS

This application is related to the following ~ U.S. Provisional patent application having serial number 60/164,021, entitled "Method and Apparatus to

Provide Custom Configurable Business Applications From a Standardized Set of Components," filed August 23, 1999; Utility patent application having serial number 09/440,326, entitled "Method for Providing Custom Configurable Business Applications from a Standardized Set of Components," filed November 15, 1999; Utility patent application having serial number 09/439,764, entitled "Apparatus to

Provide Custom Configurable Business Applications from a Standardized Set of Components," filed November 15, 1999; Utility patent application having serial no. 09/658,415, entitled "Method For Developing Custom Configurable Business Applications," filed September 8, 2000; and Utility patent application having serial no. 09/658,416, entitled " Integrated Design Environment For A Commerce Server

System," filed September 8, 2000; Utility patent application having serial no. 09/697,271, entitled "Method for Providing Template Applications For Use By a Plurality of Modules," filed on the same date herewith; Utility patent application having serial no. 09/691,461, entitled "Method and Apparatus for Providing News Client and Server Architecture and Protocols," filed October 17, 2000; Utility patent application having serial no. 09/684,491, entitled "Adapter and Connector Framework for Commerce Server System," filed October 4, 2000; Utility patent application having serial no. 09/702,148, entitled "Workflow for Execution on a Workflow Engine and Methods Thereof," filed on October 30, 2000; — each of which are hereby incorporated by reference in their entirety.

FIELD OF THE INVENTION

The present invention relates generally to a presentation layer which provides for display of data and interaction with the user via a hierarchical set of templates used to dynamically generate the user interface via HTML or equivalent technology (i.e., SGML, WML, etc.). By changing the display specifications, the behavior specifications, and templates, the user can customize behavior as well as the look and feel of the user interface.

BACKGROUND OF THE INVENTION The prior referenced applications provide for methods and apparatuses for creating custom configurable business or channel applications from a standardized set of components. More specifically, the referenced invention allows each business to select from a set of applications, customize that set of applications, and/or develop new customized applications from a set of development components. The prior applications provide for a server based method wherein best-of-breed services and/or applications are integrated in a seamless fashion and offered to enterprise businesses which develop customized business service applications through using the system. The server device is previously (and hereafter) referred to as the Asera Commerce Server (ACS).

The ACS includes a Commerce Server that provides a core set of technology

(or application) services. A unique architecture and framework are provided by the Commerce Server which facilitates development and use of customized applications. Most interactions with external systems or users are managed via business objects. The service application code is maintained separate from the data. This enables the system to quickly include (and/or change) new business processes or technology components without having to write substantial amounts of new code. The business result is more rapid customer deployments and/or modifications that are customized to include (if desired) the proprietary or competitive business practices of a contracting company.

The ACS can be viewed as a form of ASP (Application Service Provider). An

ASP is generally an outsourcing business model. The ASP business model requires an open and extendable architecture that allows a system to implement a customer specific business solution in a short period of time. The ACS takes best-of-breed applications and incorporates them into one integrated solution to provide the ASPs. The architecture is scalable and extensible. A customized business (or channel) application solution is built for each enterprise company. The solution uses a "modular" or step-wise or "plug and play" approach towards building new applications. An enterprise company can then quickly acquire a turn-key e-commerce solution to automate their channel relationships. The system presents little (or no) risk for the enterprise company because a solution is built by the present system. The costs of undertaking such a development exist as a fixed development cost of the system. Any resulting customized solutions are implemented in considerably less time than previous systems. The enterprise company might pay for the application services on a cost per transaction, or a fixed fee basis.

The ACS is used to capture the particularized (or specific) business processes for a given customer, and these business processes are converted into a set of customized applications. The ACS uses business steps and rules to construct the application. The objects are data representations. The steps are business operations with a defined set of input and output ports, with each port also having a defined set of parameters. The business rules are used to capture customer specific business practices. A unique tool that employs a graphical user interface (GUI), allows a developer to arrange various steps (or composite steps) into business processes, or workflows. The tool provides library catalogs of steps to be applied to the various objects. The connections between steps are also verified as correct. A graphical display of the business process is shown, and rules can thereafter be applied to provide further customization by conditionally tagging certain points. Hence, to create a business process (or application) for any given business, tools are provided which allow modules (or steps) to be plugged or dropped into the potential process. The steps can be moved, or the connections modified. An initial person-to-person (or other type of) interview with the business (or customer) can be used to produce the framework for arranging the steps according to the needs of that particular business

(i.e. customized routines). The modular aspect of the present system allows this to be done — and modifications made — in a relatively quick fashion. For instance, if a process has been created, but the customer wants it to behave in two different manners, then certain rules can be applied to provide the desired results, depending on conditional triggers that can be associated with the underlying business objects.

In general, Internet transactions can be divided into two categories: 1) business-to-business transactions, and 2) business-to-consumer transactions. Most solutions to automate transactions have dealt with business-to-consumer interactions. As such, these interactions are much more straightforward than business-to-business transactions. In a business-to-consumer transaction, the merchant supplies a "storefront" or web site that offers products to any number of diversified consumers who might wish to view this web site. The consumer then purchases a product via a selection and payment method, and the product is thereafter shipped to the consumer. On the other hand, when one business deals with another business, there is a much greater amount of business processes and customization in the transactions that occur. The ACS system therefore provides a customized business application that runs on the server and communicates with outside data sources.

In the context of prior ACS systems, a presentation layer is provided that dynamically generates HTML pages from a hierarchy of templates. As shown in Figure 1, each display page is viewed as a combination of a Wire Frame 100 (which is defined by the application developer), and a Master Template 102. The Master Template 102 contains various Micro Template tags. In the present example, these tags include MainMenu 104, AppMenu 106, and AppError 108. Note that these particular tags are created for use throughout a multitude of pages. The Wire Frame and the Master Template are combined to create a macro template 110 (wherein the presently described version combines Wire Frame and Master Template at runtime during the HTML generation process). The wireframe, MainMenu, AppMenu, and

AppError all contain Micro Template tags, each represented by MT (i.e., 112, 114). The Micro Template tags are replaced at runtime by dynamically generated HTML snippets. The type of display object determines the processor used to generate these snippets.

Under prior implemented versions of the ACS, each application uses customized code located in Java Micro Templates to render any advanced HTML elements (i.e., tables, forms, image maps, etc.). An interactive step is used to encapsulate the state needed to display information to the user and to retrieve input values back from the user. A pre-step of an interactive step is used primarily for preparation of UI (User Interface) data and a post-step is used to convert data returned from the UI back into business objects and values to be used by the application. The pre-step retrieves values from the parameters passed in on the input port of the interactive step and passes these values as inputs into the Micro Template processors. The post-step receives the name/value pairs passed in from an HTML forms submission, or from name/value pairs passed in through a URL. The post-step iterates through these name/value pairs and sets values in business objects and values of parameters on the output port of the interactive step. In addition, the post-step is responsible for setting which output port of the interactive step should be used for the next transition.

Business objects have been created that serve only to specify the layout of an HTML form. These pseudo business objects specify each of the form items as attributes and define business object configuration filters to define the layout and captions of the form. For instance, the width of the form (i.e., number of items across) is hard coded into the Micro Template processors and the attributes of the business object are defined to directly correlate to the form. Some of the display characteristics of the items in the form are also hard coded into the Micro Template processors. The mixing of view characteristics with the business objects of a system has negative impacts on the customizability and configuration of the applications built in the system. For example, a future business process change may require a change in the attributes in a business object, but if these attributes are tied to a particular screen being displayed by the application, the attributes cannot be changed without impacting the application.

What is needed in the presentation layer is an implementation that will remove as much of the specialized (and hard-coded) code from the layer, and place the functionality in reusable display components available to all the applications. The preparation of the UI data that might have been handled by the Java code in the pre- interactive step should be replaced by a declarative block (XML, or otherwise) in the interactive step. In addition, the Display Filters should be separated from the business object configuration and should be used to specify the look and feel of the UI.

SUMMARY OF THE INVENTION

The present invention provides a presentation layer that makes application development and customization easier and more efficient by reducing the amount of Java code written for a specific application. A set of standard display objects is offered to the application developer. Customization parameters (i.e., look and feel) are specified in filter and configuration files using a defined XML specification. The presentation layer handles the mapping of business object values into and out of (User Interface) UI elements using the configuration and filter files.

The presentation layer allows a user to specify how to display data on the UI. The presentation layer relies on a set of hierarchical templates to dynamically generate the HTML or equivalent pages. By changing the display specifications and the templates, the user can customize the look and feel of the user interface. Data to be displayed can be specified across dimensions including content, structure, style, format, behavior, and control.

Content refers to the actual data to be displayed. Structure refers to the overall layout. For example, the structure describes whether the information is laid out in a table or in a list. The structure also refers to the cell alignment, cell width, etc., for an individual table. Style refers to the font style, the color, etc. Typically the style refers to the elements that affect the look and feel of a page, but do not contain any semantic meaning. Format refers to the format of the data. For example, the format indicates if a given number is an amount, a currency, or a percentage. To distinguish between format and style, the use of a red colored number to represent a negative value on a balance sheet would be a format information rather than a style information. Behavior refers to what components should be displayed on a page, i.e. data and actions. For example, the behavior indicates if the user can select a single value or several values from a list. The behavior also specifies the entitlement mechanism. Control refers to the specific component that is used to implement the behavior. For example, the control specifies the type of selection tool to use, such as radio button, check boxes, or lists.

The presentation layer interacts with a given workflow at the Interactive Step level. The Interactive Step is comprised of an input port, output ports, and an action map. The interactive step represents a single interaction with the user. Different versions of the same UI page can be generated based on the data to be displayed and information from the current user session. The information from the user session can include but is not limited to user specific entitlement information as well as system information such as the default time zone or locale. The presentation layer further includes Master Templates, Wire Frames, Micro Templates, Behavior Filters and Display Filters. The Master Template provides the overall page layout common to all applications. Tags within the Master Template are placeholders to display dynamic content. The content for System tags are defined in the Presentation Layer configuration and can be overridden by the respective Interactive Steps. Overridden system tags are defined by respective Interactive Steps, and Wire Frame tags are mapped to Wire Frame files within the Interactive steps. The Interactive Step will use either a specified custom Master Template, or a default Master Template. Dynamic content in the Master Template is thereby populated at runtime.

Wire Frames referenced in the Master Templates are replaced with Wire Frame content at runtime. The Wire Frames contain Micro Template (MT) tags, which are placeholders to display dynamic content. The content for a Micro Template Tag typically comes from a Display Filter associated with the Interactive step. The Display Filter describes how the data and actions should be displayed on the browser. Data and actions to be displayed are specified in the Behavior Filter associated with the Display Filter.

There may be multiple Display Filters for a given Behavior Filter, in order to display the same information using different layouts. Each Display Filter candidate is associated with a set of criteria. The first candidate whose criteria are satisfied will be selected at runtime. More than one Behavior Filter can also be defined for entitlement purposes.

A Behavior Filter is an XML (or other functional type) file that maps the attributes of the business objects and view data objects (from the input parameters of an Interactive Step) to behavior elements. The Behavior Filter also specifies the actions associated with input parameters into behavior elements, and assigns a name and a behavior type to those behavior elements. The Behavior Filter also specifies the behavior dimension of the user interface.

A Display Filter is an XML (or other functional type) file that translates the behavior elements defined in the Behavior Filter into specific UI controls. The

Display Filter assigns a display type to each behavior element. A Display Filter also specifies the dimensions of the user interface, including for instance control, structure, and style.

The content of a Micro Template Tag may also come from another Interactive Step. This step may be called by inclusion or invocation. Under inclusion, the called step is only used for content generation. The calling step handles all the actions generated by the called step. All submits and internal links exit through output ports of the calling step. Calling an Interactive Step by inclusion requires the following parameters: step name, which is the name of the called step; and step port, which is an input port on the called step. Such an Interactive Step would be created in order to "reuse" a certain UI construct in multiple pages.

Under an invocation, the called step is used as a "window into another application." All submits and internal links generated by the called step exit through output ports of the called step. Generally, the called step must be part of an interaction flow so that when an action occurs, the output port of the called step will be stitched into another step. Calling an Interactive Step by an invocation requires the following parameters: step name, which is the name of the top level interaction composite step describing the Interaction flow; step port, which is an input port on the top level interaction composite step; and parameter mapping, which is used for mapping the input parameters of the calling step to the input parameters of the called step. Such an interactive step can be seen as a "window" into another application.

According to one aspect of the present invention, a presentation layer is provided as associated with a server device for running business applications having business objects, the presentation layer being used for rendering to a display format certain information contained in the business objects, the presentation layer comprising: at least one business object having a certain set of attributes; at least one interactive step for receiving the business object on an input port; at least one behavior filter having attributes which are assigned a logical name and having different attribute types, whereby the behavior filter specifies the attributes in the business object that are to be displayed, and describes the behavior of that attribute; at least one display filter corresponding to each of the attribute types, the display filter providing different display types for each of the attributes; and at least one display object corresponding to each display type, wherein the display object serves to render the attribute into the display format for the user.

According to another aspect of the present invention, a method is provided for a presentation layer associated with a server device for running business applications having business objects, the presentation layer being used for rendering to a display format certain information contained in the business objects, the method comprising: inputting a business object or a view data object into an interactive step through its input port; specifying via the interactive step a master template, or otherwise using a default master template; using the interactive step to call wire frames corresponding to each wire frame tag on the master template; replacing the system tags on master template and the micro template tags on the wire frames with HTML snippets, and displaying the HTML page on the browser after proper de-normalization; and using a request handler to receive information submitted by the browser and normalizing the information.

These and other aspects and advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:

Figure 1 shows a block diagram of a.prior configuration wherein the Wire Frame and Master Template are combined into a Macro Template.

Figure 2 shows, according to one aspect of the present invention, a block diagram of an Interactive Step interacting with Business Objects and a presentation layer (or portion thereof).

Figure 3 shows, according to one aspect of the present invention, a representative Master Template. Figure 4 shows, according to one aspect of the present invention, the rendered HTML page.

Figure 5 shows, according to one aspect of the present invention, a representative Master Template.

Figure 6 shows, according to one aspect of the present invention, the generation of a menu using included Interactive Steps.

Figure 7 shows, according to one aspect of the present invention, a first and second Custom Master Template.

Figures 8A and 8B show, according to one aspect of the present invention, certain Wire Frames and Micro Template tags being replaced with display content information.

Figure 9A shows, according to one aspect of the present invention, an Interactive Step as part of a normal data flow.

Figure 9B shows, according to one aspect of the present invention, content being generated for Micro Template tags through an Interactive Step invocation and through an Interactive Step Inclusion.

Figure 10 shows, according to one aspect of the present invention, certain steps for the Micro Template tag to include display content information.

Figure 11 shows, according to one aspect of the present invention, certain steps associated with the user returning form information back through the Action Map of the Interactive Step from an included Interactive Step.

Figure 12 shows, according to one aspect of the present invention, certain steps for the Micro Template tag to invoke display content information.

Figure 13 shows, according to one aspect of the present invention, certain steps associated with the user returning form information back through the Action Map of the Interactive Step for an invoked Interactive Step. Figure 14 shows, according to one aspect of the present invention, a resulting rendered page.

Figure 15A shows a prior art example of XML being pushed through XSL to provide HTML for display.

Figure 15B shows, according to one aspect of the present invention, a Business

Object being pushed through a Behavior Filter, Display Filter, and Display Object to provide HTML for display.

Figure 16 shows, according to one aspect of the present invention, relations between example attributes in the Behavior Filter and the Display Filter.

Figure 17 shows, according to one aspect of the present invention, an

Interactive Step processing through certain Criteria associated with Candidate lists in order to select Behavior Filters and Display Filters.

Figure 18A shows, according to one aspect of the present invention, a swapping of one Display Filter for another based upon a parameter such as user type.

Figure 18B shows, according to one aspect of the present invention, a base (or parent) DF (or BF) as associated with child DFs (or BFs).

Figure 19 shows, according to one aspect of the present invention, a block diagram of certain representative elements associated with the flow of information through the presentation layer of the present invention.

Figure 20 shows, according to one aspect of the present invention, a flow diagram of certain representative elements associated with the flow of information through the presentation layer of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The presentation layer of the present invention relies on many of the same principles and components as the prior ACS presentation infrastructure, as described in the set of incorporated references. An Interactive Step encapsulates the information needed to display information to the user and to retrieve input values back from the user. The HTML page displayed to the user is described by the following elements, including Master templates, Wire Frames, Micro Templates, Behavior Filters, and Display Filters. Master templates are used to layout the overall structure of the page. Because of the level of granularity of the Master Template, a single Master Template will usually describe the majority of the pages in the system. Wire frames are used to define the detailed layout of a particular page. Wire frames are referenced in the Master Template using named tags that are replaced with the Wire Frame content at runtime. Micro template tags (MT tags) are used to indicate where dynamic content should be inserted into a Wire Frame. The Behavior Filter is used to specify the behavior of the elements on the page, while a Display Filter is used to specify the control, structure, style, and format of the page.

Referring again to Figure 1, note that the concept of the macro template 110 does not exist in the present implementation. Rather than combining the Master Template and the Wire Frames together into the macro template during design time, the connection between Master Template to Wire Frame, and Wire Frame to Micro Templates, is dynamically established at runtime.

Furthermore, the present implementation provides a presentation layer wherein the HTML is rendered dynamically by making many of the components of the UI declarative. Two different kinds of filters are provided to separate the "model" (i.e.,

Business Objects) from the "view" (i.e, the presentation layer). In the past, aspects of the display characteristics have been hard-coded into the Business Objects and associated Micro Template processors. The purpose of this presentation layer will be to remove as much of the specialized code as possible and place the functionality in reusable display components, which are available to all the applications. For instance, the preparation of UI data currently handled by Java code in the pre- interactive step will be replaced by an XML declaration in the Interactive Step. In addition, the Display Filters will be separated from the Business Object configuration, and will be used to specify the look and feel of the UI.

The overall construction or generation of a sample page is first described, with the filter separation of the presentation layer further described thereafter. Generation of Sample Page. Figure 2 shows a block diagram 200 of the Presentation Layer (or a portion thereof) interacting with a given workflow at the Interactive Step level. The Presentation Layer 202 is shown interacting with a browser 204 through HTML and with an Interactive Step 206 through a logical object. The interaction occurs in the following manner: (1) The Interactive step receives a business object 208 through its Input Port 210, and then sends its input parameters (e.g., business object 208) to the Presentation Layer 202 in a normalized format. (2) The Presentation Layer 202 de-normalizes the business objects and converts them into logical objects expressed in native format. The Presentation Layer 202 generates the HTML pages according to certain specifications (i.e., what data to display, how to display the data, what actions can be performed, how to display the actions, etc.). (3) The Presentation Layer 202 retrieves the information submitted by the browser 204, normalizes the information, and returns it to the Interactive Step 206. (4) The Interactive Step 206 exits (with a business object 214) at one of its output ports 212, based upon the actions performed on the browser 204. Note that in describing the present invention, the Presentation Layer is meant to encompass the complete set of the elements associated with taking a Business Object through the Interactive Step, including Behavior Filters, Display Filters, and Display Objects. The Business Object information is rendered into HTML, and then any return information from the Browser 204 is converted back into a Business Object for use by the overlying system.

The Interactive Step is comprised of the following components: an Input Port, Output Ports, and an Action Map. A single input port contains the list of input parameters to the interactive step. The input parameters specify the information to be displayed to and/or retrieved from the user. These parameters can be simple types, business objects, and view data objects. A view data object is a particular type of business object that only contains view specific information. For example, a business object contains a date attribute and the search form for this business object contains a start date and an end date. The start date and end date, which are only view specific, would be attributes of a view data object. The input port specifies the content dimension of the user interface. An Interactive Step can have multiple output ports. Each output port contains its own list of output parameters that corresponds to a given action performed on the browser. These parameters can be simple types, business objects, and view data objects. Only business objects and view data objects, passed in as input parameters to the interactive step, can be allowed as output parameters. The Action Map is a listing of all the actions that can be performed on the page generated in the Interactive Step. It specifies the mapping between the actions and the output ports of the Interactive step. The Action Map also specifies the repeatable/non-repeatable nature of each action (see further description below).

The Presentation Layer is comprised of components including Master Templates, Wire Frames, Micro Templates, Behavior Filters, and Display Filters. A Master Template provides the overall page layout common to all applications. The Master Template is an HTML file that contains static data as well as tags for displaying dynamic content. Figure 3 shows an example of an overall conceptual structure of a Master Template 300. The template is shown to include static content areas 302 and 304, a main menu tag 306, an app menu tag 308, and an error message tag 310. A first Wire Frame 312 is shown having MT tags 314 and 316. A second Wire Frame 320 is shown having MT tags 322, 324, and 326.

Figure 4 next shows a base example of how a particular page might be constructed. This particular construct will be referenced throughout the following detailed description, but is not meant to be limited to this example in any way. The illustrated Master Template 400 is shown to include areas similar to Figure 3, but having Interactive Steps. This includes static content areas 402 and 404, application

(app) areas 406 and 408, a Main Menu Interactive Step 410, an App Menu Interactive Step 412, and an App Error Message Interactive Step 414.

The Master Template can be specified in one of two places. A particular Interactive Step can specify a Custom Master Template, which will be used when rendering that Interactive Step. If the Interactive Step does not specify a Custom

Master Template, then a Default Master Template can be used. The Default Master Template is specified using a Named Candidate. The location of the Master Template Named Candidate is defined in a "Presentation.xml" configuration file under a tag such as <masterTemplateDef>. This file contains the configuration information needed by the presentation layer. At runtime, the Master Template Named Candidate is used to determine which Master Template HTML file to use. The Master Template Named Candidate can contain references to one or more Master Template HTML files. Figure 5 shows a typical Default Master Template 500. This template has both static content placeholders (i.e., 502, 504) and dynamic content placeholders (i.e., 506, 508, 510, 512, and 514).

The tags are placeholders to display dynamic content, and are generally replaced with dynamic content at runtime. There are two types of tags in the Master

Template: System Tags and Wire Frame tags. Common examples of System Tags might include MainMenu, AppMenu, and ErrorMessage. Note that these particular tags are created for general usage across a multitude of pages. The content of these tags is defined respectively by the Main Menu Interactive Step, the App Menu Interactive Step, and the App Error Message Interactive Step. These steps are defined in the presentation configuration and can be changed for an entire deployment.

Each Wire Frame tag is mapped to a Wire Frame file in the Interactive Step. Wire Frames referenced in the Master Templates are replaced with the Wire Frame content at runtime. Wire Frames provide the more "granular" layout of a given application. A Wire Frame is an HTML file that contains static data as well as tags for displaying dynamic content (see again 312, 320 in Figure 3). The MT tags 322, 324, and 326 are placeholders to display dynamic content.

Figure 6 shows an example of the Main Menu Interactive Step 410 being implemented with a Custom Master Template 602 having static HTML. A Wire Frame 604 is further included having Micro Templates (MT). Similarly, the App

Menu Interactive Step 412 is implemented with a Custom Master Template 606, and a Wire Frame 608 having a Micro Template (MT). The location of the Main Menu Interactive Step is defined in the Presentation.xml configuration file under an appropriate tag (or label). A candidate is specified in the Micro Templates map to determine which particular menu to show. The criteria specified in the candidate should be used to determine which application is running, and to which application suite the application might belong. Using this information, the criteria should determine the Display Filter.

Unlike the Main Menu Interactive Step, which is the same for all applications with the ACS, the App Menu Interactive Step is unique to each application. An

Application Name, defined in each application Interactive Step, is used to determine which Application Menu Interactive Step should be used to generate the Application Menu. Once the right Application Menu Interactive Step is determined, the candidate specified in the Micro Templates section of the Application Menu Interactive Step is used to determine what Display Filter to use to generate the App Menu. Like the Main Menu, the App Menu can use the criteria found in the candidate to dynamically display the correct menu. For example, the criteria can be used to determine anything from what buttons to show on the menu (i.e., role-based entitlement), to what buttons are active and/or disabled.

The Wire Frame itself is an HTML file that is inserted in place of the Wire Frame in the Master Template HTML file. The Wire Frame can contain two types of tags for dynamic data: Form Tags, and Micro Template Tags. Form tags might include beginning and end tags, which are automatically converted into proper HTML Form tags. Micro Template tags have tag names that are used to identify certain content that is used to replace this tag in the Micro Template Map (see below) in the Interactive Step.

Certain styles of pages might be used. These include JavaServer Pages (JSP) and Cascading Style Sheets (CSS). The JSP 1.1 specification (hereby incorporated by reference) defines a tagged markup/scripting language that is used to combine logical scripting commands, Java objects, and static text (i.e., HTML, XML, etc.). JSP extends the Java Servlet API and runs inside a Servlet engine which allows a JSP implementation to handle request/response type semantics such as HTTP. JSPs allow for redirection and inclusion of other JSP pages. Redirection can be used to partition the request/response semantics. "Request JSPs" can be used to handle incoming requests and serve as a request layer, invoking business object steps and business processes as necessary. These JSPs can then call "Presentation JSPs" to handle the presentation semantics using the data modified/created by the request process. A JSP can instantiate Java objects and invoke methods on these objects. If the underlying Servlet engine is running the same JVM as the application server, then the JSP has access to any global objects in the system. The JSP 1.1 specification describes a Tag Extension mechanism that can be used to extend the standard JSP template tags. These extended tags can reference actions that are imported into the JSP page from a tag library. The benefit of using this Tag Extension mechanism is that a standard tag library can be defined and then imported into all of the JSP pages in a system. Tag libraries also ease the use of tools to create the JSP pages since the tag library specifies a well-defined set of actions and parameters that are allowed in the JSP page.

CSS is an attempt to separate style from content. With a browser that fully supports CSS, HTML authors will be able to position items on the page without the use of <table> or <frame> tags that are common today. The <table> tag can then be used to mark tabular data without implying a table presentation. Authors will be able to use <em> (emphasis) to place semantic meaning on the data without being concerned how the browser will actually display the data. Different style sheets can then be used for different viewing mechanisms. When pages are viewed online, the emphasized information can be used (for instance) as a red colored font; when pages are printed in black and white, the information can use a bold font; and when the pages are accessed via an auditory browser, the information will be sound emphasized (and the like). CSS allows the definition of a "CLASS" that has a set of style rules. A "CLASS" can then be reused on multiple components in a document and across multiple documents. CSS rules are scoped, and rules can be "layered" on top of one another. When a rule is declared, the rule remains in effect until the scope of the rule ends or until an overriding rule is defined. For example, if a font rule is declared that makes all text italicized (for instance), then all the text appearing after the rule will be in italics until another font rule is declared that makes the text non- italicized. When the scope of the second font definition ends, the text will once again be in italics until the scope of the first font rule ends. Multiple styles can be applied to the same document. The precedence or cascading order of the styles is resolved using a weighting scheme. Each CSS rule has a weight that can be calculated and the rules are then ordered and applied based on these weights. One feature of the cascading styles is that both the author and the reader of the document can define styles for the document. Depending on the weights of the author/reader's rules, the final presentation of the document will represent a combination of two sets of styles.

Interactive Step. The purpose of the Interactive Step in the interaction flow is to describe an interaction with the user. In order to describe this interaction, the step must define what is displayed to the user, as well has how to handle information submitted by the user. Each Interactive Step contains the following elements: Declaration elements, including Input port, Output ports, and an Action Map; Implementation elements, including Master Template (optional), Wire Frame Map, and Micro Template Map. The Input Port, Output Ports, and Action Map together make up the declaration of an Interactive Step. The declaration of an Interactive Step is the minimal information needed to define the relationship between an Interactive Step and the steps around it in the interaction flow.

There are three types of Interactive Steps: (1) Virtual; (2) Implementation; (3) Normal. The Virtual Interactive Step only defines the declarative portion. The Virtual Interactive Step is used as a placeholder or interface step in the interaction flow. A Virtual Interaction step is stitched into the interaction flow, and the actual implementation is chosen dynamically at runtime. The selection of the Implementation Interactive Step is handled through a candidate's block that uses criteria to choose an Implementation Interactive Step. Each Virtual Interactive Step has a 1-to-many relationship with Implementation Interactive Steps.

The Implementation Interactive Step is used in conjunction with the Virtual Interactive Step to achieve dynamic Interactive Step selection. The Implementation Interactive Step "implements" the interface specified by the Virtual Interactive Step, but not the declaration block. The Implementation Interactive Step must specify values in the implementation block that match with the elements in the declaration block of its associated Virtual Interactive Step. For example, the Action Names specified in the Behavior Filters specified by the Implementation Interactive Step should match with the Action Names in the Action Map specified in the Virtual Interactive Step.

The Normal Interactive Step specifies both a Declaration block and an

Implementation block.

The Interactive Step has one input port. All connections to the Interactive step must come through this single port. The port can have multiple parameters, each of which has a name and a type. The Behavior Filters use the parameter names from the input port of the Interactive Step to identify elements to be displayed. An Interactive Step can have multiple output ports. Both input parameter objects and simple name/value pair type parameters can be sent out of the Output Port of an Interactive Step. The simple name/value pairs can come from either an HTML input parameter or from a parameter on the Input Port. The objects must come from the Input Port of the step. The Interactive Step cannot implicitly instantiate new objects. For example, if a Quote object is one of the parameters on the output port of an Interactive Step, then a Quote object must be passed into the Interactive Step. The Interactive Step can modify the Quote object, but the Interactive Step cannot create a new Quote object itself. The simple name/value pair type parameters can come from either the input parameters of the Interactive Step, or from values entered in entry fields of the UI generated by the Interactive Step.

The Action map is used to map actions defined in the Behavior Filters to particular Output Ports of the Interactive Step. Particular actions can be noted as repeatable (via an indicator, or the like), and such actions respond the same each time they are used.

Custom Master Template. The Master Template specified in the Interactive Step is used to override the default Master Template that is defined for the entire deployment. The Custom Master Template can include the MainMenu, AppMenu, and AppError messages from the Default Master Template by using appropriate tags. Figure 7 shows two examples of Custom Master Templates. The first Custom Master

Template 702 is shown to include all of the standard tags, but in different positions than the Default Master Template shown in Figure 5 above.

Alternatively, Interactive Steps that define a Custom Master Template can specify custom menus by specifying its own Micro Templates to define new menus. Since the Menus are generated by using Interactive Steps, an Interactive Step with a

Custom Master Template can mimic the standard construction of the menus using Wire Frames/Micro Templates/Display Filters/ and Behavior Filters. The second Custom Master Template 704 is an example of Main Menu using the standard Wire Frame mechanism. The WF Tag specifies the location of the custom Main Menu generated by the Interactive Step. Wire Frame Map. Wire Frames define the layout of elements in a section of a particular page of the application. The Wire Frames section in the Interactive Step maps the Wire Frame tag found in the Master Template (either in the default Master Template or the custom Master Template) to a Wire Frame HTML file. This mapping is handled at runtime using a standard criteria evaluation mechanism. The simplest implementation of the Wire Frames section in the Interactive Step defines a single Wire Frame Candidate with no criteria. In this case, the same single Wire Frame is always used regardless of when or how the page is accessed. In addition to standard HTML components, each Wire Frame can also have Micro Template Tags. A tag name is used to determine which Micro Template content to use to replace the tag at runtime. The tag name has an entry in the Micro Template Map in the corresponding Interactive Step.

Micro Template Map. The Micro Template Map section in the Interactive Step maps Micro Template tags found in the Wire Frames of the Interactive Step to the content that replaces the Micro Template tags at runtime. The content comes from a

Display Filter definition, or from another Interactive Step. A Display Filter Selection mechanism uses a standard criteria evaluation mechanism to select a Display Filter used to replace the Micro Template tag. The Display Filters are used to generate HTML, as described in further detail below.

Figure 8A shows the page of the present example, with a representative Main

Menu 802 and App Menu 804 implemented in the appropriate areas. A Wire Frame Main area (WF_Main) 806 is shown being implemented by an example Wire Frame 810. A Wire Frame Side area (WF_Side) 808 is shown being implemented by another example Wire Frame 812. Each Wire Frame is used to layout specific portions of a particular application page. The Wire Frame is specific to the

Interactive Step in which it is referenced. A given Wire Frame is not reused across different Interactive Steps. Each Interactive Step can have multiple Wire Frames defined for each Wire Frame Tag found in the Master Template. Note that Figures 8A and 8B give an example of having single and multiple Micro Template Tags in a single Wire Frame, rather than multiple Wire Frames for a particular Wire Frame Tag in the Master Template. An example Micro Template selection 814 is shown associated with the Wire Frame 812. Figure 8B shows the Wire Frame 810, along with a first example Micro Template selection 820 associated with MT 819, and a second example Micro Template selection 822 associated with MT 821.

During a normal workflow, the various steps comprising the workflow will be encountered and executed. The presentation layer interacts with a given workflow at the Interactive Step level. The Interactive Step is comprised of an input port, output ports, and an action map. The interactive step represents a single interaction with the user. Figure 9A provides an "Order Page" example. A Composite Step 902 is shown receiving the incoming data flow. The Composite Step 902 includes an "Order Page" Interactive Step 904. The information is rendered as a display 906, with HTML 908 being sent, and an HTTP response expected in return. The display is shown to include an example order with an identification (id) of "101", and status of "open." Three different user options are presented, including "Submit," "Save," or "ShowOrderList." A choice of Submit would send the appropriate HTTP response 910 back to the Interactive Step 904. The Action within the Interactive Step might therefore be "Submit" with an associated parameter of the order id, "Save" with an associated parameter of the order id, or "Show Order List" with an associated parameter of an iterator (as used for displaying the list). If the resulting Action is: Submit, then a Submit Functional Composite Step (FCS) 912 is executed; Save, then a Save FCS 914 is executed; or Show list, then a Show Order List FCS 916 is executed.

Interactive Step Call. The content for a Micro Template Tag can come from another Interactive Step. The called Interactive Step will typically describe some reusable content. For example, the Main Menu and App Menu are generated using an Interactive Step call. There are two different types of Interactive Step calls - Inclusion and Invocation. In the following context, the Primary Interactive Step is the

Interactive Step whose Micro Template Tag is being replaced with content. The Called Interactive Step is either the included or the invoked Interactive Step.

In both cases, the declaration of the Interactive Step Call requires certain elements, including a Step Name and a Step Port. In addition, the Interactive Step Invocation mechanism might need other elements, including Step Parameter

Mapping. The parameter mapping information is used to map the input parameters of the Primary Interactive Step to the input parameters of the Invoked Interactive Step. If the parameters names are the same or if no parameters exist, then no parameter mapping is necessary. Figure 9B shows an example Wire Frame 952 that contains the two Micro Template Tags MTl 954 and MT2956. As an example, MTl 954 will be an Interactive Step Inclusion (of an example Interactive Step 958). MT2 956 will be replaced with content from an Interactive Step Invocation (of an example

Interactive Step 960).

Interactive Step Inclusion. A Called Interactive Step can be included in the Primary Interactive Step, and the Called Interactive Step is generally used for content generation. The Primary Interactive Step handles the actions that are generated by the Called Interactive Step. Submits and internal links exit through output ports of the

Primary Interactive Step. The Step Name is the name of an Interactive Step and the Step Port is the name of a port on the Interactive Step. This results in (at least) two implications of an included Interactive Step being used purely for content generation: (1) The Action Map of the Primary Interactive Step must support all actions of the included Interactive Step. (2) The input port parameters of the included Interactive

Step must be a strict subset of the input port parameters of the Primary Interactive Step (i.e., the parameters names must match).

Since the Called Interactive Step is used primarily for content generation, all of the actions in the Display Filters of the Called Interactive Step must exit through the output ports of the Primary Interactive Step. Accordingly, the actions in the Called

Interactive Step Display Filters should primarily map to the actions in the Action Map of the Primary Interactive Step. Also, since the included Interactive Step gets its input data from the Primary Interactive Step, the parameters needed by the included Interactive Step are a subset of the parameters available to the Primary Interactive Step. The parameter names should match since all the actions and parameters submitted from the included Interactive Step exit through output ports of the Primary Interactive Step.

Referring to Figure 10, a representative example of the Include generation process 1000 is shown for an Interactive Step. The Wire Frame 1002 is shown having a static content area 1004, a first Micro Template Tag (MTl) 1006, and a second Micro Template Tag (MT2) 1008. MTl 1006 is shown to "include" the

Called Interactive Step 1010, which includes a Custom Master Template, a Wire Frame Map, and Micro Template Map. The resulting Custom Master Template 1012 is shown to include a Wire Frame 1014 and a MT Tag 1016. The MT Tag 1016 results in the example Interactive Step 1018, which has four text entry fields (Vail - Val4) and a submit button. Note that the dotted arrow between elements 1010 and 1012 is not meant to represent the flow of information, but instead represents the content for a given Interactive Step 1010 (with the content being 1012). Similarly, the dotted arrow between 1016 and 1018 represents the content for a given Micro Template Tag 1016 (with the content being 1018).

Figure 11 shows a related example 1100 wherein the results are submitted in a form created by the Included Interactive Step. The Primary Interactive Step 1102 is shown having a MT Tag (MTl) 1104 and an Action Map 1106. MTl 1104 is shown to include the Called Interactive Step 1108. Certain example values have been provided in the form for each of the values one through four (i.e., "test", "123", "abc", and "def", respectively). The Action is mapped to an output port of the Primary Interactive Step 1102 using the Action Map 1106 of the Primary Interactive Step.

This is invoked when the user selects the "submit" button 1110. The values are then set to the entries provided, as shown by 1112. The workflow execution continues based on what is stitched to the output port of the Primary Interactive Step.

Interactive Step Invocation. When the Primary Interactive Step invokes an Invoked Interactive Step, the invoked Interactive Step is used as a "window into an application." All of the submits and internal links generated by the invoked Interactive Step exit through an output port of the Invoked Interactive Step. Since the actions of an Invoked Interactive Step exit through the output ports of the Invoked Interactive Step, the Invoked Interactive Step must be a part of an interaction flow, and the definition of the interaction flow must be available to the Primary Interactive

Step. The Action Map of the Invoked Interactive Step is used to support the Actions of the Invoked Interactive Step.

The Invoked Interactive Step should be a part of the interaction flow so that when an action occurs, the output port of the Invoked Interactive Step instance will be stitched to another step. Thus the Step Name referenced by the Primary Interactive

Step must be a Top Level Interaction Composite Step (TICS), and the Step Port must be an input port of the TICS. The input port parameters of the TICS should be a subset of the input port parameters of the Primary Interactive Step. Parameters names may be mapped from the parameter names of the Primary Interactive Step to the parameter names of the TICS. The parameter names may be mapped from the parameter names of the Primary Interactive Step to the Parameter Names of the TICS since the TICS is a global entity and may be invoked programmatically, declaratively, and through URL connections.

The input parameters of the actual Invoked Interactive Step can come from any of the data sources normally available to an Interactive Step that is stitched into a View Composite Step (VCS). These data sources include, but are not limited to, the input parameters of the TICS or VCS, a call to a Functional Composite Step, some data retrieved in a Bridge Step, or the Application Object of the Invoked Interactive Step.

Figure 12 shows a representative example of certain elements 1200 comprising an Interactive Step Invocation. The Wire Frame 1202 is shown having a static content area 1204, first Micro Template Tag (MTl) 1206, and a second Micro Template Tag (MT2) 1208. The TICS 1210 is shown being invoked by MT2 1208 through Portl 1212. The VCS 1214 is invoked through Port2 1216. In this instance, a Bridge Step 1218 is used, followed by an Interactive Step 1220. The Interactive Step 1220 is thereafter shown to define a Custom Master Template 1222, a Wire

Frame 1224, and a Micro Template (MT) Tag 1226. The MT Tag 1226 implements the example form shown as 1228. Note that the dotted arrow between elements 1220 and 1222 is not meant to represent the flow of information, but instead represents the content for a given Interactive Step 1220 (with the content being 1222). Similarly, the dotted arrow between 1226 and 1228 represents the content for a given Micro

Template Tag 1226 (with the content being 1228).

Figure 13 shows a follow-up example 1300 (using the same elemental references as Figure 12). The Action is mapped to an output port of the Invoked Interactive Step 1210 using the Action Map 1302 of the Invoked Interactive Step. This is invoked when the user selects the "submit" button 1304. The values are then set to the entries provided, as shown by 1306. The workflow execution continues based on what is stitched to the output port of the Invoked Interactive Step. The above described steps, when put together, show the overall process for rendering a viewable page. The process starts with the Master Template, as shown in Figure 4. First the Main Menu, Application Menu, and the Error Message tags are replaced with content. Thereafter, the Wire Frame Tags are replaced using the Wire Frame Map in the Interactive Step. The Micro Template Tags in each Wire Frame are then replaced with content using the Micro Template Maps (see, e.g., Figures 8A and 8B). The final result is the completely rendered page 1400, as illustrated in Figure 14.

The specialized usage of the Behavior Filters and Display Filters is now further described. Note that Figure 15A shows a prior art example of a rendering technique.

The XML file 1502 is pushed through XSL 1504, which is then rendered in HTML (or the like) 1506 for viewing on a browser. XSL refers to Extensible Stylesheet Language, and is a language for creating modules that describe how data sent over the Web using XML (Extensible Markup Language) is to be presented to the user. XSL is based upon and extends the Document Style Semantics and Specification

Language, and the Cascading Style Sheet (Level 1) standards.

Figure 15B next shows the usage of separate Behavior Filters and Display Filters in order to render display information. In general, Behavior and Display Filters are used to specify the elements that appear on the UI. The Behavior Filter is used to specify the behavior of elements on the page, while the Display Filter is used to specify the control, structure, style, and format. An important consideration in the implementation is to make the definitions of the UI declarative. Accordingly, aspects of having certain parts of the filters incorporated within the coded Business Object have been remedied. The present system implements a separation of the model and view, with the model being the Business Objects, and the View being the current

Presentation Layer. The filters are removed from the Business Objects and described now in association with the Interactive Steps.

In Figure 15B, the Business Object 1510 is shown to have certain attributes (i.e., 1 through n) associated therewith. The Business Object first gets pushed through the Behavior Filter 1512, which contains a subset of the original attributes

(i.e., 1 through m). In the Behavior Filter 1512, the behavior of each attribute in the final display is described. For instance, attribute 1 might be a text entry, attribute 2 might be a link, attribute 3 might be a single select entry, and so forth. A Display Filter (DF) 1514 is next shown, wherein there is a separate DF for each attribute type. Thereafter, a Display Object 1516 is used to convert the information into HTML.

In addition to describing the behavior of the attributes, the attributes are given logical names. The reason that each of the attributes is given a logical name is that a particular attribute may be displayed multiple times on a single UI page. Each instance of the attribute may have different behaviors and/or display properties. For example, a page may display the Order Ship Date as a static (behavior) text (display) element. In addition, the page may also display the Order Ship Date as a text entry (behavior) and text field (display) element. Although the input port parameters that these two elements reference is the same, the logical entities that they refer to are different and are described separately in the Behavior and Display Filter.

The attributes in the Behavior Filter are all referenced via path expressions from the input port parameter name. As a result, the "attribute 1" in the Business Object will not map directly to "attribute 1" in the Behavior Filter. Figure 16 further demonstrates certain example relationships between a Behavior Filter 1602 and a Display Filter 1604. For instance, an example attribute in the Behavior Filter is shown as Product^ΛPrice 1606, which is given a logical name of CurrentPrice 1608. This attribute is of the type "text entry" or "static" as shown in the type field 1610. As a text entry, a value would be set into this attribute on the screen. On the Display

Filter side 1604, the logical name CurrentPrice 1608 would be used to identify the incoming attribute information. From this logical name, the DF would discern that the information is of a text entry type. A choice of either "text field" or "text area" (1612) is provided as to how to implement the text entry. A second example is shown. On the Behavior Filter side 1602, the attribute is shown as Product^ΛType

1620. The assigned logical name is CurrentType 1622. The behavior type is shown to be "singleselect" 1624, wherein a single value out of a list of values will be selected. On the Display Filter side 1604, the logical name CurrentType 1622 is again used to identify the attribute. The type 1626 is shown to include radio buttons, or a single select list.

The present construct provides the ability to describe the behavior of a display, without needing to know the exact end-appearance of the display. In other words, the Behavior Filter can be said to describe a contract that will be enforced by the Display Filter. This construct also allows for the DFs to be quickly switched out for each other. For instance drop-down lists might need to be replaced with radio buttons (or the like).

As described above, the Master Template and Wire Frame are combined at runtime. The system provides the general ability to define multiple Wire Frames, and then select the correct ones within the Interactive Step. In general, a workflow will proceed to an Interactive Step, which will then invoke a Master Template. A Wire Frame must be chosen, and the Interactive Step utilizes a series of Candidates and Criteria in order to achieve this selection process. Figure 17 shows an example

Interactive Step 1700 that describes (in a basic manner) this process.

Each Wire Frame Tagname 1702 associated with the Interactive Step has an associated Candidate List 1704. Associated with the Candidate List is a series of Candidates, i.e., Candidate 1 (1706), Candidate 2 (1708), Candidate 3 (1710), and so forth. The Candidates, in this case, correspond to Behavior Filters. Candidate 1

(1706) is shown to correspond with BFl (1718). More than one Candidate might also be associated with the same Behavior Filter. Candidates 2 and 3 (1708 and 1710) are shown corresponding to BFn (1720). For each Candidate, there is an associate set of criteria (1712, 1714, and 1716, respectively). The process will walk through each Candidate and evaluate the (various) criteria. Whenever all the criteria are evaluated as "true", then the associated Candidate is selected. Further, if the entire list is processed, and none of the criteria sets is evaluated as "true", then a default Candidate can be defined and used.

As further detailed above, within each of the Wire Frames there are defined various Micro Template Tags. A similar selection process is employed with

Candidates and Criteria, wherein the Candidates correspond to Display Filters. Figure 17 further shows a Microtemplate Tagname 1750 and a corresponding Candidate list 1752. Candidate 1 (1754), Candidate 2 (1756), and Candidate 3 (1758) are shown with associated Criteria (1760, 1762, and 1764). Again, whenever all the criteria are evaluated as "true", then the Candidate is selected. Candidate 1 (1754) is shown corresponding to DF1 (1760), Candidate 2 (1756) is shown corresponding to DF2 (1762), and Candidate 3 (1758) is shown corresponding to DF3 (1764). The DF's shown might be used to switch out various aspects of the displays, such as which buttons to use, or the like. The DF's are thereby used generate the content to replace the MT tags. In either case (i.e. Wire Frames and MT tags), the general concept of "criteria" can be used for any situation that involves choices (i.e., user status, language for display, etc.), with the "criteria" based upon any of a variety of input parameters.

Aspects of "inheritance" can also be applied to both the Behavior Filters and the Display Filters, wherein a certain part of the display might be changed based upon the value (or type) of a certain input. A manager might be allowed to perform certain tasks on a page, whereas a sales representative or an end user might only be allowed to perform more limited (or static) tasks. For the most part, the tasks that each of these persons will be allowed to perform on a page is primarily the same. However, there may be certain parts of the display that need to be specifically swapped out depending upon the user type (or other such conditional variables).

For instance in Figure 18 A, a quote page 1800 is shown, which will have a

"Quote ID" 1802, and a series of other fields 1804 which are basically the same on each such page. However, the "Discount" area 1806 might need to be swapped out, depending on the status of the user. If the user type is an "end user" (or "sales representative", or the like), then a static field is provided through the use of DFl 1808. If the user type is a "manager", then a dynamic field (i.e., capable of being edited) is provided through DF2 1810. In this particular example, the Discount is a number that only the manager should be capable of entering.

Note also that instead of having many different Display Filters to describe the different components of the page 1800, a Base Display Filter 1820, as shown in Figure 18B, is used which describes all of the elements within the overall page.

Separate inherited DF's (i.e. DFl 1822, and DF2 1824) are used, each of which contains one attribute. This attribute serves to override the associated attribute used for the display of the page. The filters DFl and DF2 are separate named entities, and are used as Candidates in the Interactive Step (as described above). Each filter DFl and DF2 can be thought of as "child" elements which reference the "parent" Base

Filter 1820. As indicated in Figure 18B, Behavior Filters can also utilize aspects of inheritance. A similar construction is used, wherein a Base BF is provided, and one attribute might be changed in child BF's which reference the parent Base BF. Similarly, this inheritance mechanism prevents a developer from having to re- describe an entire BF (that might already be similar to another).

Globalization and Internationalization. The Behavior elements on each page generally stay the same. However, different languages might require different behavioral actions. For instance, the pages might be displayed in different languages. Typically a language such as German might result in text fields that are much larger after translation. Accordingly, it may not make sense to display the information in the same way in different languages. Certain Display Filters might therefore be swapped-out, as conditioned upon the language choice, to accommodate the proper display of the data. For certain locales, the behavior or semantics of a UI page may change. For example, the Japanese address fields require additional rows that are not present in a standard American address. In these cases, both the Behavior and

Display Filters may need to be swapped-out, as predicated by the target locale.

Figure 19 next shows a block diagram of the set of components 1900 (generally described above), which can be used to render information (or data) for display to a user. In the past, the Java code area developed by the application developer was large and inclusive, with Java code even being an encoded part of the Business Objects.

The present embodiment limits the Java code area 1920 to the Display Objects 1922 and 1924. In this flow, the Business Object 1902 is shown as an input to the Interactive Step 1904. The Interactive Step takes the Business Object and pushes it through the Behavior Filter 1906 and Display Filter 1908 (as generally described above). After the DF 1908, the descriptions need to be taken and converted into

HTML. This is done by the Display Objects 1922, 1922'. Note that 1922 and 1922' are the same entity, but in terms of implementation it can be split into two elements.

Note that there is a different Display Object for each Display Type. As the process proceeds through the Display Filter and encounters each element, the right type of Display Object is called in order to render the information. The Display

Object thereby renders, or denormalizes the data into a locale specific transformation. The resulting HTML 1930 is sent to the User 1932. Note that there can be single element Display Objects, which might include text objects, text fields, radio buttons, and so forth. Additional Display Objects might display aggregate information, such as a table or the like. A table is generally produced via an iterative technique, which processes row after row of Display Objects. A block Display Object can also be used to provide structure around multiple Display Objects.

The user might thereafter type in some input data. For data coming back from the User 1932, the information needs to be handled so that it will be directed to the proper Business Objects. In prior instances of such implementations, the data coming back from the user would contain many different parameters. These would need to be parsed through in order to determine their associations and/or destinations. The present implementation instead handles the data coming back from the User through the same Display Objects. The potential values that might come back from the user are known by the Display Object, which was already used to render the information going out the User. The Display Object 1922 thereby takes the incoming values and normalizes (or transforms) such information back into Business Objects, as representatively shown by the Business Object 1924. This Business Object is thereafter passed back out of the Interactive Step 1904.

As a result of this implementation, the application developer does not need to go through and parse the returning HTML form data in order to figure out what the parameters are, where they came from, and/or what values might be assigned to such parameters. The Java (or other such) code 1920 associated with the Display Object layer instead provides both the denormalization and normalization functions for rendering the data. Times and/or dates would be an example of a common type of data that would exist in the system in a certain standardized format (i.e., UTC). This data would need to be denormalized according to the user's locale. Any return data from the user would then need to be normalized again into the canonical format.

The overall display process is further illustrated in the representative elements 2000 of the block diagram, as shown in Figure 20. In steps 2002 and 2004, a Business Object (BO) 2006 or a View Data Object (VDO) 2007 enters an Interactive Step 2008 through its input port. From the Interactive Step 2008, a Master Template

2010 is specified. Otherwise, a default Master Template is used. In step 2009, the Interactive Step 2008 also calls the Wire Frames 2012 corresponding to each Wire Frame Tag on the Master Template. The Wire Frames 2012 thereafter call the associated Micro Templates 2014 through the MT tags, and the corresponding Filters 2016 as satisfying the Criteria for Candidate selection. In step 2018, the systems tags on the Master Template and the Micro Template tags are replaced with HTML snippets. The HTML page 2020 is displayed on the user's browser after proper denormalization. In step 2022, the Request Handler 2024 receives the information submitted by the browser and normalizes the information. In step 2026, the Interactive Step 2008 receives the normalized information and selects the proper output port based on the action performed on the browser. In steps 2028 and 2030, the Interactive Step updates the corresponding Business Object 2006 or View Data

Object 2007, as applicable.

Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Therefore, the described embodiments should be taken as illustrative and not restrictive, and the invention should not be limited to the details given herein but should be defined by the following claims and their full scope of equivalents.

Claims

CLAIMSWhat is claimed is:

1. A presentation layer associated with a server device for running business applications having business objects, the presentation layer being used for rendering to a display format certain information contained in the business objects, the presentation layer comprising:

at least one business object having a certain set of attributes;

at least one interactive step for receiving the business object on an input port;

at least one behavior filter having attributes which are assigned a logical name and having different attribute types, whereby the behavior filter specifies the attributes in the business object that are to be displayed, and describes the behavior of that attribute;

at least one display filter corresponding to each of the attribute types, the display filter providing different display types for each of the attributes; and

at least one display object corresponding to each display type, wherein the display object serves to render the attribute into the display format for the user.

2. The presentation layer of Claim 1, wherein the components of the presentation layer are declarative.

3. The presentation layer of Claim 2, wherein the interactive step invokes a master template.

4. The presentation layer of Claim 3, wherein the master template contains wire frame tag areas.

5. The presentation layer of Claim 4, wherein the interactive step is configured to select an appropriate wire frame for the wire frame tag area.

6. The presentation layer of Claim 5, wherein the potential wire frames are arranged as a list of candidates with associated criteria, and when those criteria are met the candidate is selected, and an associated behavior filter is used for the wire frame.

7. The presentation layer of Claim 4, wherein the wire frame tag areas include micro template tag areas.

8. The presentation layer of Claim 7, wherein the interactive step is configured to select an appropriate content for the micro template tag area.

9. The presentation layer of Claim 8, wherein the potential content descriptors are arranged as a list of candidates with associated criteria, and when those criteria are met the candidate is selected, and an associated display filter is used for the micro template.

10. The presentation layer of Claim 1, wherein a base behavior filter is used to describe behavior on a majority of a display area, and associated behavior filters are used to reference the base behavior filter and affect the behavior on a subset of the display area.

11. The presentation layer of Claim 10, wherein the associated behavior filters affect the behavior through at least one attribute.

12. The presentation layer of Claim 1, wherein a base display filter is used to describe displays on a majority of a display area, and associated display filters are used to reference the base display filter and affect the displays on a subset of the display area.

13. The presentation layer of Claim 12, wherein the associated display filters affect the displays through at least one attribute.

14. The presentation layer of Claim 1, wherein the behavior filters and display filters can be swapped out with other such filters to modularly affect the rendered output.

15. The presentation layer of Claim 1, wherein the display object is used to normalize returned information from the user back into a returned business object for use by the business applications running on the server device.

16. The presentation layer of Claim 15, wherein the returned business object is reflected out of the interactive step via an output port.

17. The presentation layer of Claim 1, wherein the display format includes HTML, SGML, XML, WML, or their equivalents.

18. A method for providing a presentation layer associated with a server device for running business applications having business objects, the presentation layer being used for rendering to a display format certain information contained in the business objects, the method comprising:

inputting a business object or a view data object into an interactive step through its input port;

specifying via the interactive step a master template, or otherwise using a default master template;

using the interactive step to call wire frames corresponding to each wire frame tag on the master template;

replacing the system tags on master template and the micro template tags on the wire frames with HTML snippets, and displaying the HTML page on the browser after proper de-normalization; and

using a request handler to receive information submitted by the browser and normalizing the information.

19. The method of Claim 18 , which further includes :

receiving the normalized information via the interactive step, and selecting the proper output port based upon the action performed on the browser.

20. The method of Claim 19, which further includes :

updating via the interactive step the corresponding business object or view data object as applicable.