Abstract:
An XML client abstraction layer for providing an XML page description as an abstraction of an HTML page at design time. A style sheet XSLT translator is used to derive the run time code from the XML page. Additional features or improvements may be added through an XML parser.

Description:
FIELD OF THE INVENTION 
   This invention relates to an XML-based client abstraction layer for enabling the design of web-based applications with reusable elements. 
   BACKGROUND OF THE INVENTION 
   Web-based application development may entail many different HTML pages. When designing such applications, it could be a tremendous investment of time and resources to separately code each page. This investment is wasteful, especially when many similar or identical elements appear in multiple pages. 
   Additionally, web developers who are developing HTML templates are not usually forced to use existing functions and design interfaces. Thus, several different templates could end up being developed to perform the same functions. Each of these templates may well be unique because different programmers program with their own unique styles. Because of this uniqueness, central design changes are not practical. Thus, not only are development costs high for such applications, support costs are also. 
   It would therefore be beneficial to develop a library of elements that are reusable in design time. A need exists for a framework for creating and using reusable elements in design time to generate HTML pages. This framework would preferably be runtime and device independent. 
   SUMMARY OF THE INVENTION 
   The present invention consists of using an XML page description as an abstraction of the HTML page at design time. This XML description is used to define layout information, rater than data, as it is usually used for. A style sheet XSLT translator is then used to derive the run time code from the XML page. By doing this, development can be standardized. Normally, HTML programmers tend to use their own special programming techniques to develop code. By using the abstraction layer, you can bypass this step and enhance the maintainability of the code. 
   Additionally, by using the XML client abstraction layer, other features can be mixed into the generated HTML page without actually changing the templates. Instead, the insertion or improvement of features can be done in the abstraction layer through an XML parser. 
   The technique of the present invention is usable with both new technologies and existing technologies. 
   An embodiment of the present invention provides a framework for creating and using a library of reusable elements in design time to generate HTML pages. 
   Another embodiment of the present invention provides a framework for permitting central HTML template changes to web based applications. 
   As such, it is an object of the present invention to facilitate the creation and use in design time of a library of reusable elements to generate HTML pages. 
   It is a further object of the present invention to facilitate central HTML template changes to web-based applications. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a block diagram of an XML client abstraction layer according to an embodiment of the present invention. 
       FIG. 2  is a block diagram of a definition layer defining syntax for an XML client abstraction layer according to an embodiment of the present invention. 
       FIG. 3  is a block diagram of a client-side framework for an XML client abstraction layer according to an embodiment of the present invention. 
   

   DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   The present invention will be better understood by reference to the accompanying drawings. The use of the term “layer” herein is a reference to a grouping based upon function. The grouping may or may not be physically dependent on another layer(s) for interfacing with other layers. 
   Referring to  FIG. 1 , an XML client abstraction layer  100  for use in design time is shown. The XML client abstraction layer  100  contains a definition layer  105  that defines the syntax used in XML client abstraction layer  100  and sets the parameters for the XML that is permitted to be used. Definition layer  105  is described in more detail hereinafter with reference to  FIG. 2 . 
   XML client abstraction layer  100  also includes integration logic XSLT  110 . Integration logic XSLT  110  defines the translation rules for translating XML templates. Because XSLT has a very thorough syntax check, a syntax error is returned if inappropriate syntax is generated. This minimizes the occurrence of errors that would crash an application during runtime. 
   Integration logic XSLT  110  includes client specific logic  111  and middleware specific logic  112 . Client specific logic  111  is responsible for abstracting the client on which the web-based applications will be used from the XML. Client specific logic ill may be, for example, a client-side framework as is discussed herein with respect to  FIG. 3 . Middleware specific logic  112  is responsible for abstracting the middleware on which the web-based applications will be used from the XML. 
   Templates  115  a–x are present. These are XML templates. 
   An XML Parser  120  is present as well. It is utilized to publish applications to the middleware  130  for use during runtime. Changes to templates such as new features or improvements can be added through this layer. 
   Middleware  130  contains template folders  140  for storing the published templates and application servers  141 ,  142  and  143 . A number of applications servers may be supported. These may include Java application servers, other standards-based applications servers and/or proprietary application servers. 
     FIG. 2  depicts the details of definition layer  105 . Definition layer  105  has three major functionalities. Functionality  150  is the interface functionality. Interface functionality  150  defines data containers sent to web servers  141 ,  142  and  143 . It also defines screen-to-screen communications, parameters and GUI components. 
   Event functionality  160  handles XML client abstraction layer application events, such as getDetail. Event section  160  is triggered by HTML events, such as onClick. It also provides for manipulation of GUI components, such as set/read values, and interfaces, such as sent/set parameter. 
   View functionality  170  defines the layout of the HTML page. It provides different views for different user profiles and different layout types. View functionality  170  uses user interface components including layout components, such as group box, and input components, such as input fields. 
   Referring now to  FIG. 3 , a client-side framework according to an embodiment of the present invention is now described. The client-side framework offers special functionality that can add features to pages. One such feature is a means for communication between pages. This is especially helpful when a user may have multiple web pages open. 
   The client-side framework may be implemented using client-side languages such as JavaScript, VBScript, etc. Preferably, JavaScript is used. 
   In order to provide such a framework, the client-side language can be enhanced to provide object-oriented features, such as inheritance. Also, a library is provided for developers, so they do not need to do any actual client-side language programming (for instance, JavaScript). 
   The client-specific logic layer  111  may comprise a client-side framework  111   a . Client-side framework  111   a  is comprised of a number of layers and provides for event control, session management, dynamic loading of content, controlling and monitoring of user input, click stream analysis, device locking, remote control, runtime debugging and client-sided event recording. 
   The first layer of client-side framework  111   a  is client-side object layer  200 . This layer is a new language derived from the client-side language (for instance, JavaScript) that permits the use of object-oriented techniques, so that methods and attributes can be transported from one class to another. These techniques include the declaration of classes; the declaration of attributes and methods within a class; the instancing of objects according to a class declaration; constructor declaration; multiple inheritance; polymorphing, including the overriding and overloading of methods; helper functions such as “instanceOf” and “marshall” for object serialization; and unrestricted access to super classes and their attributes and methods. The objects demonstrate identical behavior in their functionality, independent of the browser version. 
   Client-side object layer  200  provides reusability, maintenance and extensibility. The technique requires the properties and methods declaration be run through only once. This provides a significant performance advantage. It means that object properties and methods are linked only once, that is when the first instance of the class is instanced. 
   The second layer of client-side framework  111   a  is object pool layer  210 . Because the various client-side objects from individual windows and frames are isolated units, problems exist with object assignment and intercommunication. Object pool layer  210  is provided in order to address these problems. Object pool layer  210  encapsulates all the objects in a common object framework so that they all have the same structure because the structure of the objects within the pool is critical to proper intercommunication. Thus, object pool layer  210  effectively breaks the borders between frames and windows. 
   The third layer of client-side framework  111   a  is linking layer  220  and handles linking of HTML objects. HTML objects have restricted functionality. Client-side language functions are frequently used to supplement this functionality. However, there is no direct relationship between an HTML object and a specific client-side language instance that determines the behavior of the individual HTML object. 
   Linking layer  220  links the HTML object to a client-side language object. This is a one-to-one coupling. The properties of the client-side language object determine the behavior of the HTML object. The HTML object and the client-side language object reference each other and share their functionality. Intercommunication occurs by way of this referencing. Using layers  200  and  210 , one can then include HTML objects in the object pool. 
   By providing linking layer  220 , a programmer no longer needs to bind functions to HTML. Instead, the objects are bound. For instance, an object may have a method, “validate”, that now permits validation of the HTML input data. This layer provides more flexibility since some things were not possible through ordinary binding functions. 
   The fourth layer of client-side framework  111   a  is communication layer  230 . This layer is provided in order to allow the objects to communicate with each other and to enable access from outside the object pool. This layer utilizes an event concept to provide communication. Browser-specific events are converted by this layer to event objects of the object pool (for example, user command “keypress” of an input field). An additional listener concept is added to the event model, for example, by delegation. Communication layer  230  generates event objects within the framework and sends events to those objects that need the events. Some properties of Java are present, such as event listening by delegation. 
   Management layer  240  is the fifth layer of client-side framework  111   a . When a page in a browser is replaced by another page, its contents and their client-side language data/objects are normally lost. Thus, there should be a persistent data storage facility. Techniques to enable access to cross-object data and actions both from within and outside the object pool and also to enable these actions and data to be managed are included in management layer  240 . 
   This layer contains a central instance object that coordinates management, including communication, window management, session management, object management and cloning of objects. 
   This central instance continues to exist beyond the lifetime of the frames and windows in object pool  210  and assumes a central function. It coordinates and manages the individual objects and their actions when this is necessary. It also provides central functionality. For example, saving and management of persistent data, windows management, management of the objects themselves, communication management and session management. 
   In order to store data/objects from a frame persistently in another frame, a cloning technique is utilized. This would duplicate the data and objects in such a way that the instance of the data/objects would be in the target frame. To enable the above, each object requires a method that first performs the cloning specific to that object and second, whenever an additional object is linked by “Has-a-Relation”, for example, it calls up that object&#39;s cloning method. 
   An alternative solution for retaining persistent data is that the data/objects for a frame/window would be generated in a central instance and the reference to the related frame/window would be defined. 
   The sixth layer of the framework is pool-wide tool layer  250 . Because of the introduction of the various layers described herein, pool-wide tool layer  250  is useful to simplify programming work. 
   Tools that could be included are development support tools, such as a tracer and a debugger; a tool that can record and playback user interactions; a tool permitting remote control of other browser instances; a remote debugger; a tool that can be used during runtime to look at the properties of the object pool or of the individual objects, and with which you can also call up the methods of such objects; and others. 
   The seventh layer of client-side framework  111   a  is application layer  260 . This layer includes web applications that use the functionality of the object pool. It can provide applications with special objects using possibilities provided by the framework. 
   Screen interfaces  265  a–x are similar to HTML forms in that they are data containers. They generate a web server request that may lead to a response that causes the replacement of the current page. 
   The data contained in screen interfaces  265  a–x may consist of data or objects that originate from different frames or windows. The data is collected just before the interface is triggered (e.g., before the request is generated). As the data is being collected, general operations can be carried out. For example, data can be validated. This validation either interrupts the process before the request in the event of inconsistent data or corrects the data itself. Data can also be added that is required across different applications or across a single application. This data is stored persistently and is added automatically to each relevant screen interface  265  a–x, so data does not have to be explicitly added each time. 
   Therefore, screen interfaces  265  a–x are the direct interfaces to the web applications. They feed data to the applications. 
   The information on exactly which application status is requested is contained in each screen interface  265  a–x and consists of a URL and application-specific HTTP Post/Get parameters. These destination parameters can also be encapsulated logically in a client-side language object and are then a unique reference to a particular application status. 
   Screen interfaces  265  a–x may have additional parameters. They may have a field that reflects state. 
   By utilizing the XML client abstraction layer of the present invention one can provide central change of user interface, central change of function library, central error handling, central management of browser dependencies, syntax and plausibility checks, tracing and debugging, lessening of training effort required, easily readable and understandable templates, device specific views, better performance, and increased stability. 
   Although the preferred embodiments of the present invention have been described and illustrated in detail, it will be evident to those skilled in the art that various modifications and changes may be made thereto without departing from the spirit and scope of the invention as set forth in the appended claims and equivalents thereof.