text:
A web application development environment and method employs an extensible user interface (XUI) Framework for creating GUI-managing components written in a declarative format for handling GUI components in a web application. The GUI-managing components are coordinated in a view presentation layer by a Controller in an Extended-Model-View-Controller (XMVC) pattern in conjunction with the business logic layer. The Controller is invoked by a user request for a web page and in turn invokes the GUI-managing components to parse information contained in a corresponding web application file for the requested web page in order to determine the templates and sub-templates to be invoked for handling the GUI components. Each template has a mode value which is set by mode information contained in the web application file for the requested web page. The XUI Framework has the ability to handle a rich set of GUI components without having to implement web applications development technologies. Instead, the declarative-formatted GUI components can be created and processed using lightweight technologies for client-side and server-side processing. The XUI Framework allows for the efficient authoring and processing of GUI components for a wide range of web applications.
1. A method for web application development comprising:
providing an extensible user interface (XUI) framework for developing modular and extensible GUI-managing components residing in a view presentation layer separate from a business logic layer for a given web application, wherein the GUI-managing components are written in simple declarative format referencing predefined templates to be invoked for handling GUI components to be incorporated in a view of a requested web page, and
using an Extended-Model-View-Controller (XMVC) pattern of operation of the view presentation layer wherein an XMVC Controller coordinates the functions of the GUI-managing components by invoking the referenced templates for handling the GUI components in the view presentation layer and generating a view of the requested web page in conjunction with application data provided by the business logic layer.
2. A method according to
3. A method according to
4. A method according to
5. A method according to
6. A method according to
7. A method according to
8. A method according to
9. A method according to
10. A method according to
11. A method according to
12. A method according to
13. A method according to
14. A method according to
15. A method according to
16. An environment for web application development comprising:
an extensible user interface (XUI) framework for developing a number of modular and extensible GUI-managing components residing in a view presentation layer separate from a business logic layer for a given web application, wherein the GUI-managing components are written in simple declarative format referencing predefined templates to be invoked for handling GUI components to be incorporated in a view of a requested web page, and
an XMVC Controller for coordinating the functions of the GUI-managing components in an Extended-Model-View-Controller (XMVC) pattern of operation by invoking the referenced templates of the of the GUI-managing components and delegating control to the respective GUI-managing components for managing their respective functions for handling GUI components in the view presentation layer and generating a view of the requested web page in conjunction with application data provided by the business logic layer.
17. A web application development environment according to
18. A web application development environment according to
19. A web application development environment according to
20. A web application development environment according to
[0001] This U.S. Patent Application claims the benefit of the priority filing date of U.S. Provisional Application No. 60/405,511 filed on Aug. 23, 2002, entitled "Extensible User Interface Framework and Development Environment" by the same inventor.
[0002] This invention pertains generally to tools for creating a graphical user interface (GUI) for web applications, and more particularly, but not limited to, a structural framework for and authoring, processing and rendering of modular and extensible web browser GUIs providing rich, visual interfaces normally found and experienced in desktop software applications.
[0003] When creating a web application, it has become a necessity to employ a flexible framework for building and displaying a graphical user interface (GUI), and it has also become a necessity to create rich sets of GUI elements and components to deliver an engaging user experience for a given web application. Desktop application software with rich GUIs are desired in terms of usability and user experience promoted by an advanced user interaction model where components support a vast array of dynamic controls and event handling through the user's input.
[0004] Desktop application software have become standardized around certain well-recognized "look-and-feel" appearances that allow users to intuitively learn the GUI controls for different applications, even when encountering a new application. In order for web applications to appeal to a broad base of users, it is necessary to have a development environment that supports the creation of GUI components that provide a consistent appearance in the user interface to users by emulating the look-and-feel of standard windowing environments such as, but not limited to, Microsoft Windows(TM), Motif(TM), and Apple Macintosh(TM).
[0005] On the other hand, the user interface for web applications having a set of hypermedia documents as its primary asset is commonly designed to be "destination-oriented" where each of these documents are linked via hyper-linking, and users can navigate from one page to another until he or she has found the desired page. This is in sharp contrast with the conventional desktop applications where the user interface is designed to be "task-oriented" where users click on buttons to open dialog boxes or click the menubar to see other parts of the application or to perform another or different task, etc. In recent years, the limitations of current web application development environments, in terms of delivering rich GUIs that can be intuitively interacted with by users, has proven to be the biggest business and technical issue for anyone wishing to implement a web application.
[0006] With the standard web browser as the main tool to access hypermedia documents and other remote assets on the Internet, it has become desirable to deliver complex web applications with a standard look and feel, as has been the case with stand-alone, "shrink-wrapped" software programs. However, conventional development environments for websites are weighted toward the web application's business logic and assets residing on the server-side, rather than on the user interface on the client-side. The lack of a consistent and standardized process in building user interfaces for web applications contributes to the lack of consistency between different applications, in contrast to the standardized look-and-feel of GUIs normally employed in desktop applications. Thus, conventional development environments for creating and implementing user interfaces for web applications have proven largely ineffective in delivering consistent and easily usable interfaces for users regardless of the application's complexity.
[0007] A conventional approach to delivering rich GUIs for web applications is through the use of comprehensive (heavyweight) development environments such as Java Swing(TM) for Sun Microsystems' Java environment, AWT(TM), or the Microsoft environment for creating ActiveX(TM) components. This approach has proven to be ineffective as well since it takes away from the natural ability of the Web to deliver content and other media to a variety of clients having different protocols, processing capabilities, or policies from supporting such heavyweight technologies. There have also been numerous known issues in creating GUIs in Java applets. Some ISPs and vendors even ban the use of GUIs written as Java applets.
[0008] The typical process of creating GUI components for a web page is done through HTML, JavaScript, CSS, etc. separately, and then importing them into a developed application through typical "include" statements or linking mechanisms. GUI data is normally bound or coupled with the GUI logic which normally makes the reuse of these GUI objects very difficult especially when working with multi-behavioral or multi-modal pages. One attempt to overcome these issues is disclosed, for example, in published U.S. Patent Application No. 2002/0085020, of Carroll, Thomas J. Jr., entitled "XML-based Graphical User Interface Application Development Toolkit", which describes an approach to segregate the development of the user interface from the development of the underlying application logic ("business model"). The application's graphical user interface is specified using an XML document as an application interface file. At the application's compile time, this application interface file is parsed, and the specifications therein are used to retrieve graphical screen components from an interface library to create the user interface ("view"). This approach of separating the development of then later processing interface generation in coordination with the business logic is commonly referred to as the MVC (Model-View-Controller) approach. However, the MVC approach has shortcomings in that developers are limited in composing UI components per request, and can exhibit polymorphic behavior with only limited flexibility.
[0009] The present invention seeks to overcome the issues, inefficiencies, and limitations mentioned above, as well as to enhance the development environment for web application GUIs and the usability of web applications and user experience for end users. In particular, the present invention seeks to provide a development environment for web applications that can utilize standards-based lightweight technologies, rather than heavyweight GUI processing technologies.
[0010] 1. In accordance with the present invention, a web applications development environment and method employs an extensible user interface (XUI) framework for developing modular and extensible GUI-managing components residing in a view presentation layer separate from a business logic layer for a given web application, wherein the GUI-managing components are written in simple declarative format referencing predefined templates to be invoked for handling GUI components to be incorporated in a view of a requested web page. The functions of the GUI-managing components are coordinated in the view presentation layer by an XMVC Controller in an Extended-Model-View-Controller (XMVC) pattern of operation in conjunction with application data provided by the business logic layer. The GUI-managing components parse information contained in a corresponding web application file for the requested web page in order to determine the templates and sub-templates thereof to be invoked for handling GUI components in the view presentation layer. The Controller invokes the GUI-managing components by importing respective templates and sub-templates thereof, wherein each template has a mode value which is set by mode information contained in the web application file for the requested web page.
[0011] The XUI framework employs reusable and extendable or extensible user interface (UI) content objects that can be invoked by the GUI-managing components to exhibit polymorphic behavior. The GUI-managing components are formulated in simple XML, XSL, DHTML, XHTML, and HTML statements, which can readily be handled by JavaScript and CSS for client-side processing, and XML technologies and Java Technologies for server-side processing.
[0013] In a preferred embodiment, the present invention includes systems, methods, and conventions which allow the creation of GUIs that have a "deliberate kinship" to or consistency with existing GUI development environments and tools such as Java Swing and AWT. In order to bring consistency between the development of the web application's user interface and the traditional software user interface, and so that the same efficiency, flexibility and ease of development is achieved, "deliberate kinship" is applied to emulate the techniques, patterns, conventions and standards found in the conventional development environment for Java Swing and AWT components. Deliberate kinship means the present invention and its preferred embodiment closely mimic and emulate, for example, the creation of a Swing Menu Tree component in Java or the creation of MFC Windows components of Microsoft. The present invention's extensible GUI components thus include familiar windows, split-pane windows, menu bars, tree menus and toolbars, etc., as used in standard windowing systems. This gives the ability for the given web application to be rendered with the look-and-feel familiar to a broad base of users.
[0014] The preferred embodiment provides for creating a XUI framework using XML with Object Oriented (OO) behavior. Traditionally, XML is designed to be a declarative and procedural language. By way of organizing the pattern of communication between XML documents, schemas or DTDs, and XSL templates in a hierarchical form, OO behavior is achieved, thus producing a more robust architecture and framework with modular and reusable elements.
[0015] The present invention allows rich GUIs to be efficiently and readily developed to produce a similar user experience as found in conventional client or desktop applications, while providing a huge improvement in performance, flexibility, scalability and manageability of the web application, as well as large savings in development cost.
[0016]FIG. 1 is a representation of an extensible user interface (XUI) framework for a web application development environment according to the principles of the present invention.
[0017]FIG. 2 is a representation of the traditional Model-View-Controller (MVC) pattern.
[0018]FIG. 3 is a representation of Extended-Model-View-Controller (XMVC) approach as implemented in the XUI framework in the present invention.
[0019]FIG. 4 is a representation of the interaction in the XMVC pattern between the super class and subclasses of templates to produce a polymorphism effect.
[0020]FIG. 5 illustrates how the Layout Manager delegates control (through polymorphism) to its sub-templates to execute the layout algorithm.
[0021]FIG. 6 illustrates how the Component Manager delegates control (through polymorphism) to its sub-templates to execute the layout algorithm.
[0022]FIG. 7 illustrates how the Look-and-Feel Manager delegates control (through polymorphism) to its sub-templates to execute the layout algorithm.
[0023]FIG. 8 represents the hierarchical relationship between the XFrame (topmost container of content objects) to the XContentPanel (sole child of the XFrame) and XPanels having content objects embedded in them.
[0024]FIG. 9 illustrates the communication of web page parameters by XUIOs to the XMVC Controller for the rendering of UI content objects in accordance with the Layout Manager executing a desired layout algorithm.
[0025]FIGS. 10A to 10D illustrate examples of different look-and-feels for GUIs implemented in the XUI framework.
[0026]FIG. 11 is a diagram illustrating the logic flow to invoke the Layout Manager.
[0027]FIG. 12 is a diagram illustrating the logic flow to invoke the Component Manager.
[0028]FIG. 13 is a diagram illustrating the logic flow to invoke the Localized Content Manager.
[0029]FIG. 14 is a diagram illustrating the logic flow to invoke the Look-and-Feel Manager.
[0030]FIG. 15 is a diagram illustrating an example of a BorderLayout algorithm for layout presentation regions of a web page as applied by the Layout Manager.
[0032] Since the beginning of the Web era, the development of an effective and scalable set of GUI has been and remains a challenge. Despite the advancement of web technology, standards, browsers and the proliferation of application frameworks and template engines, the problems and issues inherent to web GUIs continue to plague most web site and web applications development. These inherent issues tend to fall into two fundamental areas: the creation, deployment and management of GUI assets for a heterogeneous client environment; and usability and user experience
[0033] Since website GUIs are open to design, there are no specific standards as to how GUI elements should be constructed except for the built-in HTML form elements which are rendered based on the browser's implementation. Even so, a developer may change the appearance of a form element by using CSS. For instance, a button can be made to appear in any available RGB color instead of the default gray color. As an example, to produce an input field for an HTML page, one would code a standard tag such as:
[0034] <input type="text" name="foo" value="bar" size="25">
[0036] <script language="javascript" src="myscript.js">
[0038] One popular and standard approach to creating a scalable application architecture is through the use of the Model-View-Controller (MVC) pattern. The premise of this design is to cleanly separate data, presentation, and business logic. Most application frameworks implement this pattern. In recent years, Object Oriented (OO) programming for web applications has become a staple with the popularity of programming languages such as Java from Sun Microsystems. MVC was originally designed for Smalltalk-80198 where the user interface was created around such framework. Over time, this has been applied as a classic pattern and has gained popularity in web applications architectures. Some of the benefits have a direct impact to the most common non-functional requirements found today in web applications development such as scalability, maintainability of code, and flexibility in integration. But despite the robustness and the efficiency gained in web development when and where this pattern is applied, some limitations, and even deficiencies, have surfaced.
[0039] The conventional MVC pattern as illustrated in FIG. 2 is split into three components, i.e., a Model, a View and a Controller object. The separation of data and presentation logic allows the retrieval of application data to be isolated from the view presentation or the user interface, so that changes can be made to the visual appearance of the user interface without disturbing the underlying business logic or data. It is very difficult to manage applications where data and presentation are mixed in one piece of code. In the MVC, the Model represents the application data, which is normally retrieved from an existing database or generated on the fly through some application logic. The View represents the GUI components of the application, which are responsible for displaying visual information to the user. The Controller is responsible for coordination between the Model and the View.
[0040] However, the MVC has the following shortcomings when it comes to lower-level GUI design and implementation. When creating views, developers are limited to compose only one UI component per request, which is the whole page itself or "view" (usually the whole HTML page). This one page is normally written in a language such as JSP and employs "includes" to reuse other pre-composed UI components. In OO paradigm, this is considered as composition—one page is composed of many components. Without further control of included UI components, the "view" cannot extend these components to behave differently or to have extended or different set of data when rendered. To add behavior or data to any of the included UI components, the developers need to change the presentation logic inside the UI component's code, possibly using "if-else" or "switch-case" statements. Thus, in MVC, the View component does not support polymorphism. Polymorphism in OOP means an object can have many ("poly") forms ("morphism"). In UI development, a UI component should have the ability to be rendered in many forms when and if desired. This is accomplished through the use "if-else" or "switch-case" statements in traditional programming which offer only limited flexibility.
[0041] Referring to FIG. 1, the present invention provides an extension to overcome the limitations of the conventional MVC (Model-View-Controller) pattern by using an Extended Model-View-Controller (XMVC) pattern with a more fine-grained division of GUI-managing components. The GUI-managing components invoke predefined templates which are written in simple declarative format to enable the use of lightweight technologies for the development environment. The templates are structured in hierarchical form so that polymorphism is exhibited in the handling of UI content objects. As shown in the figure, when an HTTP request to a given web application is sent by a client user and received on the server side, the requested web page is invoked and processed by the Controller. For example, the requested page may be in the form of a JSP Page (Java Server Page) which is embedded with instances of UI Objects written in XUI API using JSTL, XTags, or other custom tags for application data requested by the user. The application data is retrieved from the business logic ("Business Layer"), for example, it may be user information contained in an LDAP directory in DSML format. The parameters for the view of the requested web page are passed to the XMVC Controller which then delegates generation of the web page view to the GUI-managing components of the XMVC pattern. The application data is incorporated and the responsive web page is sent to the client user where it is finally rendered.
[0042] The XMVC Controller coordinates the presentation of a web page view of the application data from the Business Layer with the View to be generated by the GUI-managing components residing in a "GUI Factory". As illustrated in FIG. 3, the GUI Factory may be composed of the following independent but interacting GUI-managing components:
[0043] The Layout Manager is responsible for rendering a view of a web page according to a selected layout algorithm and has its primary responsibility in the positioning and shaping of UI content objects contained in its associated "container". It is to be understood that the Layout Manager is only responsible for the positioning of the UI component and not its look-and-feel.
[0044] The Component Manager is responsible for the organization of different XSL templates for each corresponding supported UI component such as menubars, menutrees, tabbedpanes, etc. The Component Manager is also responsible for the organization of script files and stylesheet files used by each component's XSL template.
[0045] The Localized Content Manager (LCM) is responsible for managing and rendering localized content such as labels and images from a database of internationalized labels and images.
[0046] The Look-and-Feel Manager is responsible for managing and organizing a pluggable and customizable look-and-feel appearance for a view of a web page. It is also responsible for binding the appropriate stylesheets and scripts that are "plugged" into the final hypermedia document delivered to the requesting client.
[0047] The Event Manager is responsible for binding events to the appropriate event handler, methods, and functions as defined by the developer.
[0048] XUI Polymorphism
[0049] As depicted in FIG. 4, the XUI framework takes advantage of a hierarchical interaction of super class and subclasses of templates to exhibit polymorphism in hypermedia documents and pages with a number of modalities. Polymorphism is the ability for classes to provide different implementations of methods that are called by the same name. Polymorphism allows a method of a class to be called without regard to what specific implementation it provides. For example, a class named Road may call the Drive method of an additional class. The Car class may be SportsCar, or SmallCar, but both would provide the Drive method. Though the implementation of the Drive method would be different between the classes, the Road class would still be able to call it, and it would provide results that would be usable and interpretable by the Road class. With XUI, polymorphism is achieved by leveraging the "mode" attribute in the <xsl:template> element where it can receive and respond depending on what parameters are passed to it.
[0050] Multiple classes may implement the same interface (interface polymorphism), and a single class may implement one or more interfaces. Interfaces are essentially definitions of how a class needs to respond. An interface describes the methods, properties, and events that a class needs to implement, and the type of parameters each member needs to receive and return, but leaves the specific implementation of these members up to the implementing class.
[0051] Multiple classes may inherit from a single base class (inheritance polymorphism). By inheriting, a class receives all of the methods, properties, and events of the base class in the same implementation as the base class. Additional members can then be implemented as needed, and base members can be overridden to provide different implementations. Note that an inherited class may also implement interfaces—the techniques are not mutually exclusive.
[0052] Abstract classes provide elements of both inheritance and interfaces (abstract class polymorphism). An abstract class is a class that cannot be instantiated itself; it must be inherited. Some or all members of the class might be unimplemented, and it is up to the inheriting class to provide that implementation. Members that are implemented might still be overridden, and the inheriting class can still implement addition interfaces or other functionality.
[0053] Although the types of polymorphism above apply to OO languages such as Java, XUI's polymorphism falls under the third type. In XUI, the decision as to what template, action, label, or any other component to be invoked is achieved by dynamically loading a value to the "mode" attribute of the xsl:apply-templates element in XSL. Through this dynamic loading, the effect of polymorphism is achieved. The end result is that a particular template will be invoked depending on the value of the "mode" attribute of the xsl:apply-templates element.
[0054] XUI Framework
[0055] The XUI framework contains pre-built components that facilitate the rapid development of GUI components for web applications by using extensible lightweight widgets. One of the goals of XUI is to provide an environment and development process in implementing these GUI components. The preferred embodiment is intended to work with a client/server environment particularly a web environment where communication is facilitated through a request-respond model utilizing existing communication protocols such as HTTP, HTTPS, FTP, SMTP or even RMI (Remote Method Invocation). It also includes the use of Web Services wherein data and other information that may affect the behavior of the GUI components can come directly from another system outside of the current system. Although the primary target for rendering the rich GUI widgets are web browsers found in desktop computers, the present invention may also be applied to other devices such as Personal Digital Assistants (PDAs) and other portable devices such as a tablet computer capable of running a web browser.
[0056] The preferred system is developed in a hybrid format using XML and Java technologies for server side processing and creation of rich GUI components for web-based applications. XML technologies include XML documents, XSLT, XSL-FO, XPath, XQuery, XLink and XPointer. The Java programming language, developed by Sun Microsystems of Mountain View, Calif., is used in the present invention to enhance and support any areas of the framework that needs programming logic where XSL may not be able to handle.
[0057] The Extensible Stylesheet Language for Transformation (XSLT, or simply XSL), although powerful, is designed for the efficient transformation of XML documents with the use of the XML Path Language (XPath). XSL is known as a declarative language that carries "no side effects", meaning that XSL does not employ any mechanism to affect and change the state of different areas of a stylesheet through assignment operations. XSL does not have assignment operations where variables can change values through the logic process. Thus, XSL at times can be limiting when a certain effect needs to be achieved within the system. This is where the Java programming language is used with its strong Object Oriented programming capabilities.
[0059] The XUI framework is designed to facilitate the creation and delivery of hypermedia documents for web applications with rich familiar GUI components such as menubars, toolbars, combo boxes, etc. that are typically found in traditional desktop applications. It pertains generally to a web application wherein the graphical user interface (GUI) have the ability to emulate the look-and-feel of standard windowing environments without using heavyweight technologies such as Motif, Microsoft MFC, Java Swing or AWT, but rather using standards-based lightweight technologies such as DHTML, HTML, JavaScript and CSS. XML technologies including XPath and XSL both can be used for server-side and client-side parsing. This feature of the present invention sharply contrasts with the approach represented in the conventional approach, for example, as described in U.S. Patent Application No. 2002/0085020, of Carroll, Thomas J. Jr., entitled "XML-based Graphical User Interface Application Development Toolkit".
[0060] The XUI framework does not rely on any packages, classes or interfaces provided by Java's AWT, Swing, Microsoft Foundation Classes, Motif and other windowing libraries for the creation of rich GUI components but rather employs its own pre-defined and pre-built GUI components by using lightweight markup languages such as HTML, XHTML, XML and scripting languages such as JavaScript or JScript and stylesheet language such as CSS.
[0061] Referring again to FIG. 1, the XUI framework is used to create GUI-managing components maintained in the GUI Factory which are used to generate views in the form of hypermedia documents in response to client requests in a web environment with the request-response model. The GUI factory, working with the Controller, contains several parts having their own different tasks in parsing, processing, transforming, and rendering of UI components. These interacting parts are the Layout Manager, Component Manager, Localized Content Manager, Event Manager, and Look-and-Feel Manager.
[0062] The XUI framework provides a set of declarative application programming interfaces (APIs) known as Simple API for XUI (SAXUI) to be used as the main programming interface for a developer wishing to create web GUI components using the XUI framework. The current invention provides a set of generalized tags or elements that can be used to create and render rich GUI widgets without requiring the developer to create complex programs using Java or other heavyweight programming language. Pages, or more appropriately, screens are created without concern for platform-specific windowing issues. As mentioned, these GUI widgets are designed to emulate the look-and-feel of GUIs as typically found in desktop applications. The XUI framework facilitates the rapid development of rich GUIs for web applications with a set of consistent and pluggable look-and-feel types typically found in desktop applications. It is also to be understood that the XUI framework is not intended to work solely with a specific platform but can be implemented in any development environment given that the underlying technologies used herein are portable and can be used in any environment.
[0063] Although the XUI framework can sit on top of practically any J2EE framework, it is to be understood that the invention is not limited to platforms specifically designed for J2EE framework. For instance, the invention may be similarly used for developing web applications developed in the .NET environment developed by Microsoft Corp. Since the XUI framework resides in the presentation layer, it does not matter what application logic is used in the business layer.
[0064] A typical web page is created by putting together predefined HTML tags to achieve the desired look-and-feel of the page. There are also pre-built HTML form components for the creation of input fields, buttons, combo boxes, radio buttons, checkboxes, etc. These components are put together by organizing each one inside the "body" tag and may also be further organized by creating HTML tables where components can reside inside Table Data (TD) cells. When viewed in a browser, the layout of each HTML components heavily depends on the how they are written in the HTML document. By default, tags that are written one after another will be rendered from left to right.
[0065] With CSS, additional control is provided by strategically positioning such HTML components by manipulating their x and y coordinates in relation to the whole document. Positioning of these components can be controlled by using the "position" property which can be set to either "static", "absolute", "relative" and "fixed". Positioning can then further be manipulated by setting the "left" and "top" properties which takes values in the form of pixel amount.
[0066] With all the predefined HTML tags and possible CSS styles and positioning capabilities available, the capability to create sophisticated and rich GUI clients for web applications is still lacking. When a menu bar with dynamic drop-down menu is needed for a web page, developers will normally create one from scratch or re-use a pre-coded script possibly written in JavaScript, Jscript or VBScript.
[0067] The XUI framework with its pre-built extensible containers, components, and Layout Manager employing different layout algorithms, attempts to close this gap. To create a web application window with embedded widgets, the developer takes the following steps:
[0068] 1. The developer creates a JSP file that will contain the code to call the XUI APIs.
[0069] 2. When an XUI API, also know as SAXUI, is declared inside the JSP, in context this becomes an XUI Object (XUIO) since when the API is declared, the class of such API is instantiated.
[0070] 3. The developer creates containers, panels and different GUI components by using SAXUI.
[0071] 4. The developer only needs to use SAXUI instead of coding in Java or JavaScript to achieve the look-and-feel and behavior of the desired component.
[0072] 5. The underlying Layout Manager is also utilized by defining the layout algorithm for a selected component namely "xpanel". Each layout algorithm is encapsulated in each of these defining components.
[0073] 6. The JSP file is then saved inside the appropriate folder for the web application which is exposed to incoming requests from users' web browsers.
[0074] Screens in XUI are created by putting together containers and GUI components to be used by the built-in Layout Manager. This is done by creating a document definition inside a JSP file using XUI APIs (SAXUI). The GUI components come to life by declaring XUIOs (XUI Objects) written in SAXUI that work in conjunction with the Controller. XUIOs act as the intercepting agents that communicate with the Controller, which then delegates rendering control to the Layout Manager. Every component API has an XML Schema document associated with it to provide the rules as to how these elements are to be created. This ensures that developers will be guided as to how a tag should be declared. This ensures consistency between each reusable components and each page and consistency throughout the whole application. In the preferred embodiment, the W3C XML Schema Recommendation 2001 Version 1.0 is used.
[0075] A container is a type of component which can contain other components. Using a container, related components can be grouped and treated as a unit having one parent container. A container can be nested with other containers which may also contain other containers and components. Containers are simple components which have limited attributes and have the primary job of holding other components. Each container is given a name by setting a value inside the "name" attribute. By giving a name, each component within that container can now refer to its parent through the given name. A style maybe set at the level of a container that can affect the visual attributes of components it contains. For instance, a background color or pattern maybe set at this level which ultimately affects the visual representation of components within it. An event handler can also be set within a container so that event listeners are able to respond when an even such as mouse over or mouse click is fired within the container.
[0077] Each container has access to the Layout Manager that is responsible for positioning and organizing the components inside the container. When the page being requested by the client browser is created, the Layout Manager is called upon by the Controller to properly layout the components that reside in the container. Essentially, containers, through the Controller, delegate the job of laying out their components to the Layout Manager. The XUI Layout Manager implements different algorithms for organizing and laying out the components. The developer will decide as to what type of layout is necessary to achieve the desired look of the screen. These settings are then passed to the Layout Manager for further processing. This technique of defining a family of layout algorithms which can be encapsulated within each container is known in Object Orient programming as "Strategy Pattern" (ref. Gamma, Helm, Johnson, Vlissides, Design Patterns, p. 135. Addison-Wesley). XUI employs the same pattern but not through an object oriented programming language such as Java but instead through XML transformation using XSL.
[0078] The Layout Manager's main responsibility is to determine the layout of components contained in a container. It can also determine the positioning of a container relative to the top-left corner of the screen or the position of the container in relation to the position of its parent container. Positioning is achieved through the default left-to-right relative positioning or through CSS positioning by determining the x and y coordinates of the component relative to its parent container (relative positioning) or absolute positioning where the x and y coordinates are related to the top-left corner of the screen.
[0080] These predefined GUI components can be referred to as component "classes" wherein they can be instantiated through the declaration of an XUI component tag and providing the name of the component of choice by setting the "class" attribute of the tag. For example, developers can instantiate a menubar class by declaring <xui:component class="menubar"/>. Attributes and other properties for each instance of these classes are encapsulated within each instance. Thus, with encapsulation, each of these components can be reused, extended, and shared within a screen without concern for conflict.
[0081] As mentioned earlier, the present invention is built with "deliberate kinship" to existing development patterns and standards, such as J2EE or MFC, in order to bring familiarity, ease, and agility in the development of good and effective UI. Deliberate kinship means XUI development closely mimics how one software engineer may approach, for example, the creation of Swing components in Java or the creation of MFC Windows components from Microsoft. XUI's extensible GUI components include familiar windows, split-pane windows, menu bars, tree menus and toolbars. These include, but are not limited to, the following pre-defined components:
[0082] XFrame—Top-most container that produces the window. Java Swing component equivalent: JFrame.
[0083] XContentPane—A content pane is a basic container that can be used to group contents or other component within one area of the page, which is similar to SPAN or DIV tags.
[0084] XPanel—A Panel is a type of a container that can contain other containers and components. A layout algorithm is declared at this level by setting its "layout" attribute. A panel has the ability to control its own UI behavior such as background color and image, borders, etc.
[0085] XIFrame—This is the Internal Frame component which is similar to the Frame component; but this component can only appear inside the main Frame component and cannot float outside of it.
[0086] XComponent—This component is the top-most class for components and is extended by each component that is instantiated.
[0087] XMenubar—Menu bars are dropdown menus with the root items listed from left to right. A menu bar is mostly rendered along the upper edge of the windowpane.
[0088] XToolbar—Tool bars are similar to Menu bars. The main difference is that a tool bar generally holds icons or pushbuttons instead of text. This is commonly used to display frequently used tools and is usually rendered underneath the menu bar.
[0089] XMenutree—The menu tree is a component used to create expanding and collapsing vertical menus. Each menu node can be clickable and linked to an appropriate target page.
[0090] XTabbedPane—A tabbed pane displays a group of components where one component is displayed when one of the pane's tabs is selected.
[0091] XSplitPane—A split pane physically separates contents or UI components that are positioned in it. At this time, this container can only contain two components.
[0092] XToolTip—The Tool Tip enables authors to add a ToolTip to any element on the page. Authors may control the placement and duration of the ToolTip.
[0093] XButton—Unlike the built-in button in an HTML form, the XUI button is capable of rendering images and text within the button. It supports different behaviors of borders such as raised, depressed, or flat.
[0094] XIcon—A dynamic icon is a simple component that renders an icon that can change UI state based on events such as mouse over or mouse click.
[0095] Creating an XUI Screen
[0096] The first step in creating a screen with XUI containers and components is to create the main window. The present invention uses the JavaServer Pages (language) as the "wrapper" language to execute the XUI APIs known as SAXUI. It is however to be understood that using SAXUI can be done with other languages such as ASP. JavaServer Pages perform the same tasks as Java Servlets, but uses different programming paradigm. Java Servlets are created using pure Java programming where syntax follows the Object Oriented Programming paradigm. On the other hand JSPs are created using a declarative syntax similar to coding HTML. JSPs are then converted by the server into servlets and compiled to Java classes automatically. Below is an example of a simple JSP:
[0097] As shown in the preceding example, the JSP code, identifiable with the opening "<%" and closing "%>" can be seamlessly integrated with HTML code. This makes JSP ideal for creating dynamic hypermedia documents. Servlets on the other hand are ideal for creating highly programmatic content and business logic. In the manner as described above, JSP is the ideal programming wrapper for executing SAXUIs. An example below shows how creating a simple empty frame with JSP and SAXUI.
[0098] In the example above, the xui:style tag is a custom tag with an underlying Java code that contains the logic that makes it possible to pass the contained XML fragment to the default Controller file or another controller file defined and declared by the developer. The XUI code embedded within this tag is passed to Controller for further parsing and transformation.
[0099] The Controller file is written in XSL. It does not necessarily parse and transform the passed XML fragment to it, but acts as an intercepting agent so that the appropriate XSL template can be called for a particular transformation need. For example, the XSL template for processing the element named "xframe" will be passed by the Controller to the appropriate template by using the <xsl:apply-template> element. In this particular example, since "xframe" element is always the top-most container for an XUI screen, then the following template call will be applied first:
[0100] <xsl:apply-templates match="/xframe"/>
[0101] Furthermore, the XUI framework applies the polymorphism behavior wherein the process of calling the appropriate template to apply the desired modality is achieved by calling templates with the same "match" attribute value but having a particular value for the "mode" attribute of the <xsl:apply-templates> element; a particular template from a plurality of templates with the same match value will be applied based on the "mode" value. The value of the "mode" attribute comes from the "lookandfeel" attribute value of the "xframe" element from the XML fragment being parsed.
[0102] A dynamic mode value is passed to a template wherein the dynamic value is either created through an XSL variable or created by using Java extensions in XSL where the value is either pulled from a session variable residing in cache or parsed from the XML fragment being passed to the Controller. The following are examples of how polymorphic behavior is achieved through the use of the dynamic mode:
[0103] This is the Controller XSL being invoked by the JSP file showing that the xui-lookandfeel.xsl is being imported; once this file is imported, the template with the match value of "/xframe" and mode value of "setLookandFeel" can be called from the Controller. In this instance, the template having the mode value of "setLookandFeel" resides inside the "xui-lookandfeel.xsl" file. Each of these templates have a unique mode value so that when the xsl:apply-templates element is executed, it will search through the present templates including all imported templates and invoke the template having the desired mode value. Once this template is called, the rest of the processing is fully delegated to the Look-and-Feel Manager represented by the template having the "setLookandFeel" mode residing inside the file xui-lookandfeel.xsl. The ability of the xsl:apply-templates element to search through the present template and all imported templates is inherent to XSL.
[0104] This is the Look-and-Feel Manager which is a separate XSL file named xui-lookandfeel.xsl imported by the Controller XSL (note that once this file is imported into another template, all templates herein are exposed to and can be called by the importing template). In this example, the value of the attribute "lookandfeel", represented by the XPath expression "/xframe/@lookandfeel", of the "xframe" element found inside the source document is assigned to the variable named "lookandfeel". This variable is then passed to the "mode" attribute of the apply-templates element which in turn will call the appropriate template based on the desired mode. If the desired mode is not found, a null-pointer will be returned since the desired resource is not found:
[0105] The passing of a "mode" attribute is similar to calling a particular function or method in other programming languages. The difference here is that it is not a named template that is being called and the manner by which the call is made is not through the typical manner of using an "if-else" or "switch-case" programming control; rather, it is done by simply calling the same matched template but dynamically passing a "mode" attribute to it.
[0106] In the example above, the appropriate template will be called based on the value of the "lookandfeel" attribute of the "xframe" element represented in the XPath expression "/xframe/@lookandfeel". Note that the value is being passed to this template from the calling XML fragment. This value is stored into a variable with the same name for consistency purposes named "lookandfeel". This variable is then used inside the "mode" attribute of the xsl:apply-templates element by using the expression {$lookandfeel} and will process the call based on that value. The end effect is that the appropriate template where its mode value is the same as the mode value of the xsl:apply-templates element will be called.
[0107] The Look-and-Feel of screens can also be set to "Auto" wherein the proper "skin" will be rendered by way of checking the platform or environment of the requesting client. In this manner, the GUI will still be consistent across heterogeneous clients, but will have a certain level of customization by rendering a Look-and-Feel consistent to native Look-and-Feel of the given platform. For example, the Look-and-Feel of buttons is different between Microsoft Windows and Macintosh platforms. It will be appropriate if the proper Look-and-Feel of a button will be rendered consistent with the native Look-and-Feel of a button for the given platform.
[0108] Checking the properties of the requesting client is done by reading the headers of the given request. When a server receives a request from a browser, certain properties of the browser with certain values are available for the server in the form of a header variable. One of the most important headers that are helpful in determining the platform is the USER-AGENT header which contains the browser version information and the Operating System being used by the client. For example, the USER-AGENT header may contain the string: "compatible; MSIE 6.0; Windows NT 5.0" which can then be parsed by the system to determine that the client is using Microsoft Internet Explorer Version 6.0 running on Windows NT version 5.0. With this information, the Look-and-Feel Manager can then acts accordingly and bind the proper set of stylesheets to achieve the desired Look-and-Feel. Examples of web pages rendered to different standards of look-and-feel are shown in FIGS. 10A to 10D.
[0109] The following example illustrates how this scenario may work. Notice that the lookandfeel attribute of the xframe element is set to "Auto". The xframe element also now contains an immediate child element named properties which contains a child element named user-agent. The user-agent element is dynamically loaded with information by using an embedded Java statement that retrieves the User Agent information by using the "request.getHeader( )" method. The combination of the value of the attribute lookandfeel and the value of the user-agent element is then passed to the Look-and-Feel Manager for further parsing and processing.
[0110] Given the calling JSP page above, the Look-and-Feel manager will then act based on the combined value of the attribute lookandfeel and the value of the user-agent element. Since a polymorphism pattern is implemented in selecting and executing the proper template, we only need to add another template with the mode value set to "Auto".
[0111] All XUI screens start with a Frame as the top-most container. A Frame is a type of a container that functions as the main window for any web pages that use XUI components. XUI Frames have attributes such as a title, border, lookandfeel and the default icon of a given web browser and default buttons for maximizing, minimizing and closing the frame. It also supports the usual attributes of a browser window such as: Width, Height, Scrollbars, and Resizable. XUI XFrame also has the additional attributes such as isCentered, Absolute, and isModal.
[0112] An XUI Frame or window is created by extending the XUI class XFrame. Since web pages are invoked and loaded within a web browser by accessing a specific URL, an XFrame window is usually created by a predefined script invoked by clicking a link from a loaded page or through some other page event such as "ONLOAD". From this invocation is where the attributes of XFrame is applied. For example, the width and height of the frame can be set to certain values measured in pixels; the position of the XFrame window can be set to "centered" relative to the four corners of the screen and the center of the XFrame or by x and y coordinates relative to the top left corner of the screen.
[0113] As shown in FIG. 8, a frame contains one type of container, the XContentPane. XContentPane is a top-level container which contains containers called XPanels. XPanels can be nested and can contain other XPanels or they can contain components called XComponents. The ability to nest containers within containers is crucial and a necessity to design screens of much complexity in user interface.
[0114] Rendering the Screen
[0115] The process in the creation and rendition of the XUI screen begins when a client browser requests a particular address from the server where the web application is residing. The request is intercepted by a web server; and through the typical MIME Type mapping, the request is delegated to another server application which is able to handle a JavaServer Page request. A portion of the Controller is responsible for determining if the requested page should be recreated and delivered to the client or a pre-built page with the same components, look-and-feel, etc. can be retrieved from cache and delivered to the client. Each of the main documents that produce a screen is created in JSP embedded with predefined XUI custom tags. Custom tags are tags created to be part of code library to facilitate the rapid creation of JSP pages without coding in Java. A tag library allows programmers to reuse Java code by reusing tags from the code library. Once built, the code library provides a simple set of custom tags than even non-Java programmers can use.
[0116] However, it is to be understood the not all XUI elements and APIs are written as custom tags. From the surface, XUI elements resemble any custom tags and any other declarative languages. XUI elements are pure XML elements which as passed to corresponding XSL templates for processing and transformation. The present invention includes one important tag, the xui:style. This custom tag is used to embed the XUI API elements within it.
[0117] In the preceding example, by creating and using a custom tag named xui:style, any elements within the opening and closing tags will be passed to the XUI Controller for further processing. The xui:style custom tag is written in Java and is invoked whenever the tag is embedded within a JSP page. This custom tag and any other custom tags within of the XUI framework tag library, including all other elements are bound to the namespace: http://www.jway.com/xui-1.0.
[0118] The xui:style tag can contain an additional attribute to over-ride the delegation of processing to the default controller file. When the xui:style custom tag's attribute named xsl is not present, the underlying Java code delegates the processing to the default Controller file found inside <APP-HOME>/XUI-INF/conf/ folder. The name of the file is "controller.xsl". A developer may decide delegate the processing to another controller by simply adding a value to the xsl attribute of this custom tag. For example:
[0119] XUI Controller
[0120] The XUI Controller is the intercepting agent which controls the communication within XMVC and sends different parameters and delegates actions to the GUI Factory which contains different communicating parts having distinct responsibilities in rendering the desired GUI. The Controller delegates control to GUI-managing components such as the Layout Manager, the Component Manager, the Localized Content Manager, the Look-and-Feel Manager, the Event Manager, and other resources such as repositories and databases.
[0121]FIG. 9 illustrates how four distinct user interface objects (XUIOs) in the JSP page correspond to different components or services of the web application model and are used to communicate with the Controller. The Controller delegates rendering the appropriate components and communicates with the Layout Manager for executing a selected layout algorithm for the response. The Controller also handles rendering decisions based on the communicated information. The XUIOs can be as course-grained or as fine-grained as needed. They can be as big as a whole page or as small as a single UI component such as a button or textbox. They can be embedded within each other or can be independently controlled by multiple controllers.
[0122] The Controller uses one of the strongest attributes of an Object Oriented programming language wherein the pattern of polymorphism is applied. In a typical web application, the process of applying dynamic-ness to pages is achieved by creating importable code components and templates and thereby swapping these components and templates depending on the nature of the request. This is achieved through the use of programming controls such as If-Else and Switch-Case. The invention applies a different approach in creating dynamic screens for dynamic web applications. The preferred method is achieved through the application of polymorphic behavior in XSL without the use of heavyweight programming language such as Java. It passes a dynamic mode value to an XSL template wherein the dynamic value is either created through an XSL variable or created by using Java extensions in XSL where the value is either pulled from a session variable residing in cache or parsed from the XML fragment being passed to the Controller. In the manner described above, the polymorphic approach in delegating control to the proper component template provides a robust and highly flexible system. This type of system facilitates the ease of management of such components and the ability to scale without revising or re-architecting the current system.
[0123] Layout Manager
[0124] As shown in FIG. 5, the Layout Manager package consists of a master template (xui-layout.xsl) and a plurality of templates for each supported layout algorithm. The master template is exposed to the Controller as the xui-layout.xsl template; all of its contents by default are exposed to the Controller by way of importation through the xsl:import element. The xui-layout.xsl template contains other templates that are responsible for executing the different layout algorithms. For example, the XUI Layout Manager supports the following layout algorithms:
[0125] FlowLayout (default)—lays out the components inside a container from left to right as they are defined hierarchically within the document.
[0126] BorderLayout—Defines five specific containers which are given distinct geographic identifiers such as NORTH, SOUTH, WEST, EAST, and CENTER. Each of these containers can container other containers and component by declaring their positions through such geographic identifiers. For instance, a button component can appear inside the NORTH container by setting its "layout" attribute to "NORTH". An example of these BorderLayout containers is shown in FIG. 15.
[0127] The Layout Manager uses the same polymorphic pattern wherein it determines which layout algorithm template is to be used by parsing the "layout" attribute within the "xpanel" element. The value of the "layout" attribute is then passed to the "mode" attribute of the apply-templates element within the XSL so that the appropriate layout algorithm can be called.
[0128] In FIG. 11, the logic flow for invoking the Layout Manager is illustrated. Upon receiving the HTTP request from the client user, the JSP file is invoked and a custom tag written in the file invokes the Controller. The Controller imports the template for and delegates control to the Layout Manager to parse and transform the markup information contained in the JSP file. The Layout Manager then delegates control to the appropriate sub-template for the execution of the selected layout algorithm, which can then import the encapsulated CSS or JavaScript components. The Layout Manager uses one of the strongest attributes of an Object Oriented programming language wherein the pattern of polymorphism is applied. In a typical web application, the process of applying dynamic-ness to pages is achieved by creating importable scripts, stylesheets and templates and thereby swapping these resources and templates depending on the nature of the request. This is achieved through the use of less flexible programming controls such as If-Else and Switch-Case. In the invention, a more flexible and powerful approach is used to obtain polymorphic behavior in the XSL without the use of heavyweight programming languages such as Java.
[0129] The following are examples of how the pattern of polymorphism is achieved by manipulating the "layout" attribute of the component. Whatever the value of this attribute is, it is ultimately passed to the Layout Manager for the proper positioning of the components. Hence, the execution of the layout algorithm is fully delegated to the Layout Manager by manipulating the contents of the "layout" attribute.
[0130] The following "xpanel" is to have the default "flowLayout" algorithm with the absence of the "layout" attribute:
[0131] <xpanel opaque="true" name="standard">
[0132] The following "xpanel" is to have the default "flowLayout" algorithm with the existence of the "layout" attribute, but the value is left blank:
[0133] <xpanel opaque="true" name="standard" layout=" ">
[0134] The following "xpanel" is to have the default "flowLayout" algorithm with the existence of the "layout" attribute, but the value is an unrecognized value:
[0135] <xpanel opaque="true" name="standard" layout="foo">
[0136] The following "xpanel" is to have default "flowLayout" layout algorithm through an explicit declaration of the desired layout.
[0137] <xpanel opaque="true" name="standard" layout="flowLayout">
[0138] The following "xpanel" is to have the "borderLayout" layout algorithm as explicitly declared in the "layout" attribute:
[0139] <xpanel opaque="true" name="standard" layout="borderLayout">
[0140] As mentioned, the effect of polymorphism is achieved by the Layout Manager wherein only template call is made instead of the lengthy and non-flexible approach of using if-else or choose-when statements. In the manner described above, the polymorphic approach in delegating control to the proper component template provides a robust and highly flexible system. This type of system facilitates the ease of management of such components and the ability to scale without revising or re-architecting the current system. The following examples further illustrate how polymorphism is used to apply different modalities by creating one template call.
[0141] The following example illustrates how custom tags written in SAXUI are structured and organized within a JSP file. In this example, there are two panels defined where in "panel—1" is to be laid out using the default "flowLayout" layout algorithm; whereas "panel—2" is to be laid out using the "BorderLayout" layout algorithm:
[0142] The following example illustrates how the Controller, which is being invoked by the JSP file, shows that the xui-layout.xsl is being imported; once this file is imported, the template with the match value of "//xpanel" and mode value of "setLayout" can be called from the Controller. Once this template is called, the rest of the processing is fully delegated to the Layout Manager represented by the file xui-layout.xsl:
[0143] This is the Layout Manager which is a separate XSL file named xui-layout.xsl imported by the Controller XSL (note that once this file is imported into another template, all templates herein are exposed to and can be called by the importing template). In this example, the value of the attribute "layout", represented by the XPath expression "self: node( )/@layout", of any "xpanel" element found inside the source document is assigned to the variable named "layout". This variable is then passed to the "mode" attribute so that the apply-templates element will call the appropriate template based on the desired mode. If the desired mode is not found, the default layout algorithm is applied:
[0144] Component Manager
[0145] The Component Manager determines which XSL component templates are to be used to generate the desired GUI component. Each corresponding template for each component is ultimately responsible for rendering the component. They are also responsible for binding the appropriate scripts and stylesheets for the given component. As shown in FIG. 6, the Component Manager is invoked by the Controller and in turn delegates control to the appropriate sub-template for the rendering of the specified GUI components. As described previously, the Component Manager uses the attributes of the Object Oriented programming language to obtain polymorphic behavior in the GUI components.
[0146] As mentioned earlier, each GUI component is of class type "XComponent". Instead of creating multiple, named XSL templates for each component, an abstract template is created having the same value in the "match" attribute but different mode values. For example, the following declaration is intended to render a menutree:
[0147] <xcomponent name="mymenutree" class="XMenutree"/>
[0148] The following declaration is intended to render a tabbed pane:
[0149] <xcomponent name="mytabbedpane" class="XTabbedPane"/>
[0150] Both of the elements above use the same element named "xcomponent"; both will be handled the same by the Controller but will be delegated to a particular XSL template based on the value of the class as defined above. When this information is passed to the Controller, the Controller takes the literal string contained in the "class" attribute and then passing it to the "mode" attribute of the <xsl:apply-templates> element creating a dynamic template application without the use of the typical programming controls such as if-else or switch-case statements. Thus, the effect of swapping templates through polymorphism is achieved within a declarative language such as XSL. For example:
[0151] <xsl:variable name="componentClass" value="self::node( )/@class"/>
[0152] <xsl:apply-templates match="node( )" mode="{$componentclass}"/>
[0153] The preceding example shows how the effect of polymorphism can be achieved in XSL. In the first line, the value of the attribute "class", represented by the XPath expression "self: node( )/@class" of the "xcomponent" element is assigned to the variable named "componentClass". This variable is then passed to the "mode" attribute so that the apply-templates element will call the appropriate template based on the desired mode. If the desired mode is not found, a null-pointer will be returned since the desired resource is not found. In the manner described above, the polymorphic approach in delegating control to the proper component template provides a robust and highly flexible system. This type of system facilitates the ease of management of such components and the ability to scale without revising or re-architecting the current system.
[0154] A more complete version of the example above is as follows. This is the calling JSP file embedded with SAXUIs where there are two components are defined inside to different panels. The first component named "menu—1" is to be instantiated from the XMenubar class; the second component named "tabbedpane—1" is to be instantiated from the XTabbedPane class:
[0155] This is the Controller XSL being invoked by the JSP file showing that the xui-layout.xsl is being imported; once this file is imported, the template with the match value of "//xpanel" and mode value of "setLayout" can be called from the Controller. Once this template is called, the rest of the processing is fully delegated to the Layout Manager represented by the file xui-layout.xsl:
[0156] In FIG. 12, the logic flow for invoking the Layout Manager is illustrated. Upon receiving the HTTP request from the client user, the JSP file is invoked and a custom tag written in the file invokes the Controller. The Controller invokes the template for the Component Manager to parse and transform the markup information contained in the JSP file. The Component Manager is a separate XSL file named xui-components.xsl imported by the Controller XSL (note that once this file is imported into another template, all templates herein are exposed to and can be called by the importing template). Through the polymorphic pattern, the desired template is invoked by passing a dynamic mode in the xsl-apply-template element of the XSL file. The Component Manager also determines if Business Model data or UI data is referenced in the markup information. The Component Manager retrieves the Model or UI data through the I/O process and passes it to the GUI component sub-templates where it will appear.
[0157] In the following example, the value of the attribute "class", represented by the XPath expression "self::node( )/@class", of any "xcomponent" element found inside the source document is assigned to the variable named "componentClass". This variable is then passed to the "mode" attribute so that the apply-templates element will call the appropriate template based on the desired mode. If the desired mode is not found, a null-pointer will be returned since the desired resource is not found:
[0158] Application (Model or XUI) Data
[0159] The Model or XUI Data pertains to any data used for processing containers, components, and other resources within the XUI framework. Most of XUI Data is used in with components as they need data to be used as labels for example. Data can come as different forms. For example, some XUI data are preformatted in a structured XML document with an associated XML schema document which formally describes the grammar as to how the document should be structured. It uses embeddable data sets wherein data to be used by GUI components can be created in a separate file which can then be embedded by URI reference inside component declarations. By the same token, structured data sets, conforming with the same schema can be literally and physically embedded inside the <xcomponent> opening and closing tags and then passed to the controller and GUI Factory for further parsing and processing.
[0160] The following example illustrates how UI data can either be embedded by reference or can be embedded by manner of hard-coding the actual structure data set. The first xcomponent named "menu—1" will use an external data file as referenced in the "xuidata" attribute. This structured data set will then be passed to the Controller and the GUI Factory for parsing and processing. The second xcomponent named "tabbedpane—1" contains a physically embedded structure data set. The same effect will occur wherein this data set will be passed to the Controller and the GUI Factory for parsing and processing.
[0161] The following is an example of the external data file as referenced by the xcomponent named "menu—1". This file is named "menu—1.xml" which is a well-formed XML document. It is also a valid XML document as it conforms and validated by the XML schema document name "menu.xsd" as defined in the "xsi:noNamespaceSchemaLocation" attribute of the root element named "xui-data":
[0162] Localized Content Manager (LCM)
[0163] The XUI Framework also includes a Localized Content Manager (LCM) wherein its primary goal is to organize and manage the rendering of internationalized assets such as labels and images by utilizing a markup language such as XML for the storage and definition of such assets. It also provides a web-based interface for the management of such assets. From this interface, a user with the proper privileges can view, add (upload), delete, and update a given asset. Localized assets also include CSS files, Script files and other locale specific configuration or descriptor files.
[0164] A few of the major assets that the LCM handles are localized UI data (labels), transactional or business data, and images. For UI data or labels, the actual assets are stored in XML files where the structure conforms to industry standards such as TMX or XLIFF. Storing internationalized labels in XML format facilitates the ease of use and management for multi-lingual characters specially double-byte characters for Asian languages since XML's native encoding is Unicode which can handle double-byte characters by using UTF-16 encoding. The present invention does not rely on the internationalization and localization feature inherently found in the Java language itself. By doing so, the portability of the framework is well kept wherein an implementation within a J2EE environment can be ported to another environment such as NET from Microsoft Corp. without rebuilding the internationalization feature of the system.
[0165] For images and other media, descriptors of such assets are stored in XML files called MMX (Multi Media Exchange) format. The actual media assets can be stored in the file system or a relational database with physical addresses described within the MMX descriptor file.
[0166] Referring to FIG. 13, the LCM is invoked by the Controller which imports xui-lcm.xsl to parse and transform the markup information contained in the JSP file. This immediately exposes all sub-templates within it to be used for processing and transformation. Through the polymorphic pattern, the desired template is invoked by passing a dynamic mode in the xsl-apply-templates element of the XSL file. The LCM also determines if label tokens passed through the markup information reference localized content to be retrieved from the repository of localized content. The LCM is responsible for rendering these localized assets if requested by any of the components. When a component encounters an XUI Localized Content (XLC) prefix from a XUIDataset identified by the prefix xlc, the rendering is delegated to the LCM by passing to it the requested internationalized asset identifier and the preferred locale or language in the form of language-territory combination such as "en_US" for English-United States or "ja_JP" for Japanese-Japan. The xlc prefix is bound to the namespace: http://www.jway.com/xui-1.0/i18n. For example, the controller may encounter an LCM token such as xlc:title as shown below:
[0167] <menu-item label="xlc:title"/>
[0168] Control is delegated to the LCM to find the localized version of this identifier by sorting through the assets and displaying the proper asset depending on the selected locale or language. This manner of handling internationalization from the component level gives the fine-grain control as to which labels should be or can be displayed with internationalized label. If a certain label does not have an equivalent internationalized label, the developer has two choices in terms of handling the situation. First, the developer has the choice of embedding the actual label as the value of the "label" attribute of the component. With the absence of the xlc prefix, the LCM will render the label as a literal string. For example, the developer can code the following to render the literal string "Title":
[0169] <xui:menu-item label="Title"/>
[0170] The following is another example of how an XUI data set may look like with mixed content where some labels are internationalized and some are not. The first set of "menu" data set contains elements with values in the label attributes intended to be rendered in locale-specific manner given the fact that they have the xlc prefix before their names. The second "menu" data set's labels will be rendered as they are written given the absence of the xlc prefix before their names:
[0171] Rendering behavior of each component is changed through information communicated by the UI data elements and other environmental variables that is passed to all resources coming all the way from the top-most container. In this case, the root container has communicated to the controller that the preferred language is Japanese. The Controller then goes into action by shifting the encoding information, which is then inherited by each corresponding views. If for some instance the developer mistakenly enters an identifier without real internationalized label stored in the repository that can support the rendering, then a null pointer will be returned since the resource that is being requested is not available.
[0172] Look-and-Feel Manager
[0173] The XUI Framework includes a Look-and-Feel Manager to apply a selected look-and-feel type to the view presentation. As shown in FIG. 7, the Look-and-Feel Manager is invoked by the Controller and delegates control (through polymorphism) to its look-and-feel sub-templates to execute the layout algorithm.
[0174]FIG. 14 illustrates the logic flow to invoke the Look-and-Feel Manager. Upon receipt of the HTTP request, the Controller XSL is invoked by the JSP file which imports xui-lookandfeel.xsl to parse and transform the markup information contained in the JSP file. This immediately exposes all sub-templates within it to be used for processing and transformation. The template having the mode value of "setLookandFeel" resides inside the "xui-lookandfeel.xsl" file. Each of these templates have a unique mode value so that when the xsl:apply-templates element is executed, it will search through the present templates including all imported templates and invoke the template having the desired mode value. Once this template is called, the rest of the processing is fully delegated to the Layout Manager represented by the template having the "setLookandFeel" mode residing inside the file xui-lookandfeel.xsl. The ability of the xsl:apply-templates element to search through the present template and all imported templates is inherent to XSL The following example illustrates how a specific template having a look-and-feel emulating the Microsoft Windows(TM) environment is invoked dynamically. A variable named "lookandfeel" is created by using the built-in xsl:variable element and loading it with the value of "MSWindows". In the subsequent parts of the code, there are several templates having a similar "match" attribute but having distinct values in the "mode" attribute. Having the same "match" value is similar to having the same method name. In this instance, by executing the xsl:apply-templates having similar value for its "select" attribute as it is with the value of the "match" attribute of each templates, each of these templates are "targets" for template execution. But having a particular value for the "mode" attribute of the xsl:apply-templates element, it will selectively execute the template having the same value in the "mode" attribute. In this instance, the template having the "MSWindows" value for its "mode" attribute will be invoked. Different datasets can then be passed to these templates so that they can be used accordingly. The business data from the Business Layer can thus be passed to a particular template without regard to the look-and-feel that will be used to render the view of the data. A code version for this example is as follows:
[0175] Event Manager
[0176] GUIs written in any language such as Java Swing or MFC are typically event driven. They sit idle and dormant until an event occurs. An event handler then goes to work and responds to the event. In XUI, events can occur in the component level or the container level. It is important to understand that events are not programmatically created activities but rather typical, natural and expected occurrences within the screen. Without events, the application screen will not do anything and will remain idle until a certain event happens. It is also typical to fire an event by determining if the screen has been idle for a certain period of time. For example, a window can automatically refresh after 1 minute of idleness which triggers the load event. Some examples of events are clicking the mouse, moving the cursor over a component, opening a window, loading a page within a window, scrolling the scrollbar, etc.
[0177] By default, events that occur from the component level are propagated to its parents and ancestor containers, and all the way to the top-level container. An event can be propagated up to a certain level of container or it can be handled entirely within the affected component. Event propagation is determined by setting the handle-event attribute of the component. For example:
[0178] handle-event="self"—Handles the event entirely within the component
[0179] handle-event="parent"—Handles the event within the component and propagated up to the parent component.
[0180] handle-event="ancestor"—Handles the event within the component and propagated to its parent and its ancestors all the way to the top-level container.
[0183] While certain preferred embodiments of the invention have been described, it is intended that all embodiments, variations, and modifications thereof within the spirit and scope of the disclosed principles be deemed included within the present invention, as defined in the appended claims.
Patent Citations
Referenced by
Original Image


text:
University of the Incarnate Word
The University of the Incarnate Word (UIW) was founded in 1881 by the Sisters of Charity of the Incarnate Word. It's the largest Catholic university in the Southwest and the fourth-largest private university in Texas.
Monthly Archive for March, 2013
UIW hosts 3rd annual Tech Fair
Join the University of the Incarnate Word's (UIW) Department of Instructional Technology for the 3rd annual Tech Fair on Wednesday, April 3, 10 a.m.-3 p.m., in Marian Hall Ballroom and the Student Lounge on the UIW campus (Visit www.uiw.edu/map for location). The fair will feature nearly 20 vendors, an employer showcase and the UIW Lounge, […] [Read More]

subset: commoncrawl


text:
- Home
- Newshour Podcast
- Subscribe
- Editorials
- Video
- Contributors
- About Us
- Invest With Us
Continued Caution
In the past two weeks I have had the word selective or cautious in the title of my weekly writing. Without a doubt, I continue to be cautious and very selective in the stocks I hold for clients. It is important to not become overly focused on the levels of the major stock averages. For me, it is important to be focused on key support and resistance levels for the individual stocks I hold in portfolios since many stocks can continue to provide superior returns even in down markets. Conversely, even when the averages are strong individual stocks can be mired in their own private bear markets.
Leading Economic Indicators (LEI's) were mixed last week. Two regional PMI's were released last week. Both of the numbers released in April remained in expansion territory but ticked down from recent levels. The important second derivative of change, the rate of change of change, is slowing. Is this a pause or the signs of real trouble ahead? I do not know. But, at the margin things have slowed and I have become more cautious.
The S&P 500 rose 0.6% last week in very volatile trading. It is not unusual to see volatility rise during earnings season. Globally stocks went down last week with concerns over European markets spilling over and leading to weakness here. There is no question that issues in Europe have an immediate impact on trading in U.S. markets. All of the issues regarding Europe are in the public domain in my opinion. When sentiment drifts to the positive side of the ledger regarding Europe, stocks here advance. When the powers that be feel Europe will be a bigger problem than current consensus, equities sell off.
Let's look at the technical shape of the market. 73% of stocks in the S&P 500 are in sound shape technically, no change, and secondary stocks weakened by 1% as 68% of smaller stocks are in good shape technically. I have discussed several divergences in the market over the past few weeks. It is critical to keep track of developing divergences and how they could impact the markets. There have been too many recently to mention them all. There is a potential positive divergence developing as I write so let's focus on the market in real time. The four indexes I have followed in this piece are the S&P 500, Dow, NASDAQ and Russell 2000. The four key area of support for those indexes are 1356/12,700/2975/782 respectively. If all four levels give way on a closing basis it signals an acceleration of this recent sell-off. If some of the support levels are violated, but not all, it is often a sign of waning selling pressure and we can see a rally in the market. So, you now have the key technical levels I will be focusing on this week. Look to see how the markets react when those levels are tested.
With the technical picture of the market strong but weakening somewhat, I am more cautious now than at any time this year. Also, the LEI data has displayed a slowdown from recent robust growth. In this environment I am going to reduce exposure to stocks that are not performing well. I will focus on names that continue to provide superior performance relative to the broader market averages. It is critical in my work to not become overly concerned with the broad indexes. I need to focus on each name in my portfolio to see if they warrant continued ownership.
About Thomas J Smith CFA
Primary Tel: 858.487.3939
Other Tel: 888.486.3939
Fax: 858.487.3969
PO Box 503147 San Diego CA 92150-3147 USA
Thomas J Smith CFA Archive
|Bueller, Bueller
|What Are the Smart Guys Saying?
|The Catalysts for a Correction
|What If Prosperity Breaks Out?
|What Are You Looking At? How Are You Looking At It?
|Potential to Derail
|This Must Explain Why the Market Can't Go Higher?! Maybe Not
|Generals and Grunts
|Mixed Signals
|Different Take on China


text:
fishery. This effect has been termed "Darwinian debt," and has been suggested to have general applicability (Loder, 2005). That is, timescales of evolutionary recovery are likely to be much longer than those on which undesirable evolutionary changes occur. Conover et al. (2009) provided the first experimental test of this expectation with laboratory populations of Menidia menidia. They found that the selective effects of fishing were reversible, but recovery took more than twice as many generations as the original period of fishery selection. Bromaghin et al. (2008) and Hard et al. (in press), in their simulation studies of Chinook salmon, found that complete recovery of size and age structures generally required 15–20 generations or more of substantial reductions in exploitation rate or no harvest at all. However, gene flow has the potential to accelerate the rate of recovery by restoring alleles or multiple-locus genotypes associated with the trait. For example, trophy hunting might reduce or eliminate alleles for large horn size, but gene flow from areas with no hunting might quickly restore alleles associated with large horn size (Coltman, 2008).
No-take protected areas have considerable potential for reducing the effects both of loss of genetic variation and harmful exploitative selection. Models of reserves in both terrestrial (Tenhumberg et al., 2004) and marine (Baskett et al., 2005) systems support this approach for a wide variety of conditions. However, the actual effectiveness of such reserves on exploited populations outside of the protected area depends on the amount of interchange between protected and nonprotected areas and on understanding the pattern and drivers of dispersal, migration, and genetic subdivision (Palumbi, 2003; Kritzer and Sale, 2004). Some have suggested that as exploitation pressure intensifies outside protected areas, local protection could select for decreased dispersal distance and thereby increase isolation and fragmentation and potentially reduce the genetic capacity of organisms to respond to future environmental changes (Dawson et al., 2006).
We dedicate this chapter to Hampton Carson who failed through no fault of his own to convince F.W.A. of the importance of sexual selection in the conservation of salmon. We thank Joel Berger, Steve Chambers, Dave Coltman, Roger Cowley, Doug Emlen, Marco Festa-Bianchet, Mike Ford, Roger Hanlon, Rich Harris, Wayne Hsu, Dan Jergens, Gordon Luikart, and Robin Waples for providing references and helpful comments. This article is based partially on work supported by the U.S. National Science Foundation Grant DEB 074218 (to F.W.A.) and by the Arctic-Yukon-Kuskokwim Sustainable Salmon Initiative Project 607 (to J.J.H.).


text:
We apologize but we are unable to process online orders at this time as we are building a better PetSupermarket.com. To purchase any of our products, please visit one of our retail locations or visit our Amazon store here. You can find your nearest Pet Supermarket by using our Store Locator
Glass Cleaner W/Scraper by Lee's
- Our Price:
- $6.99
Available In-Store
Heavy-duty glass cleaner is 3"L x 4"W x 1"H yellow sponge backed with crushed walnut shell on a 15" stick with a scraper. Crushed walnut shell scrubbers are the best performers for removing heavy algae on glass aquariums and is non-abrasive on glass.


text:
Now Playing
Connect with Us
KRWG.ORG-The Region's Home Page
12:45 pm
Sun March 13, 2011
Changes To DNA Testing Bill
By KRWG News
New Mexico – The Senate has approved a proposal for DNA testing of anyone charged with a felony, but Democrats added what they say are civil liberty protections.
Republicans contend the changes hurt the measure. One change allows DNA samples only after a judge finds there is probable cause for a person's felony arrest. Another provision allows people to have information about a wrongful arrest or conviction expunged from governmental records. The changes were adopted on mostly party-line votes, with Republicans opposing them.
The measure passed the Senate on a 38-3 vote Saturday. Republicans say they hope the House will reject the Senate changes.
The bill proposes to expand DNA testing under what's called "Katie's Law" in memory of Kathryn Sepich, a New Mexico State University student murdered in 2003.
Copyright 2011 The Associated Press.


text:
Hello there.
Hey, I'm Jeremiah Palecek and I like to paint:)
Etsy Stuff
Free Hit Counter
Saturday, April 22, 2006
So, the other day I decided that I was going to try and paint a normal still life just to see if I could anymore. I ve worked from photographs, and and painted directly from my computer for so long that I was scared that perhaps I couldn't make a painting from some garlic and onions on a table. So I used my trusty Google image search to look at some Chardin, and Degas. Got some onions and a piece of garlic out of my cuppord, and set them up old school style on a box in my room. I have to admit, it was actually pretty fun dealing with these old problems of space, and color instead of having everything spelled out in a photo. I also feel like I should get my chops back up by doing some really boring paintings, and figure drawings. We'll see how it effects my next painting of Jesus with a condom, or a cannibal eating an arm later. And I assure you, my irreverence will return soon:) I even signed my name on it, hee hee, I feel like a real artist now, I just need the mistresses and some sort of alcohol or drug addiction to bring everything full circle into the "real" life of a guy who paints onions.
Bid on this item now
posted by Jeremiah Palecek @
Thursday, April 20, 2006
rooftops in prague
posted by Jeremiah Palecek @
Tuesday, April 11, 2006
biometric portrait
posted by Jeremiah Palecek @
Sunday, April 09, 2006
posted by Jeremiah Palecek @
Friday, April 07, 2006
posted by Jeremiah Palecek @
Thursday, April 06, 2006
I was back in my hometown, and had to cross the memorial bridge, but it was shut down, and there were workers in the center of it. I had wanted to walk across it, and there were two seperate paths. I decided to go back, and take a bus across it, the bus went quickly across, and right throught these workers who were welding. The bus was going the wrong way, and it turned out to be more like a tour bus, it went through some weird looking suburbs, and arrived at a large auditorium. I had to pay to get inside, and I could see people inside playing basketball, I waited in line, and just had a bunch of change, but while I was paying there was a lot of money just lying on the table, so I started taking it. I took a bunch of euro, and a ton of these things that more like receipts rather than money, that was from Lithuania. There was a basketball game, and I was wearing a jersey, but I also had long underwear on underneath my jersey. I never got to get into the game, and this was annoying me as I wanted to play. My jacket with al my money had fell behind the bleachers. I went underneath them, to realise that I hadn't been stealing money, but instead receipts.
posted by Jeremiah Palecek @
Tuesday, April 04, 2006
So, in honor of the great film "Hostel" (I am the only person I know that actually liked it) I decided to make my friend a hand with two severed fingers for his birthday. Jana helped with the material, and the dangling veins:)
posted by Jeremiah Palecek @
Monday, April 03, 2006
posted by Jeremiah Palecek @
Previous Post
blogging about life and other junk
This Blog has MOVED!!!!
Darth Vader Panhandling
Fish Guts in a Forest
Suburban Homiez
Cone Head
Suburban Black Helicopters
Asian Hip Hop Cyclops
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
May 2007
June 2007
October 2007
November 2007
August 2008
My Online Painting Course
Jana's Paintings from Czech Republic
Buy my book here!
Watch my videos here
My Step by Step Tutorials
My Nerdcore posse
My Dream Journal
Links I like
My Nerdcore posse
Buy some prints
Say hi, or buy a painting:)
Poems I wrote while watching TV
© Pop Surrealism proudly powered by Blogger. Template Design by
code I found on the net


text: HEMPSTEAD N.Y.— The 11th-ranked University of New Hampshire outscored No. 10-ranked Hofstra 33-3 in the first half and senior quarterback Ricky Santos threw 4 TDs in three quarters and ran for one to lead the Wildcats to a 40-3 victory over the previously undefeated Pride.It was Santos' first game back since suffering a shoulder injury in the second quarter vs. Delaware on Oct. 6.The UNH defense also came up big on the night, producing four turnovers, three by interception and another by fumble recovery.The Wildcats (5-2 overall, 2-2 CAA), as they have done six times this season, scored on their first drive of the contest, capping it off with a 1 yd run at 11:54 by senior quarterback Ricky Santos to make it 7-0, following the good PAT by Tom Manning. The drive was nine plays and covered 75 yds in 3:06 and Santos completed 5 of 6 passes for 45 yds in his return from a shoulder injury. After several UNH penalties, Hofstra (6-1, 3-1) drove down the field and Rob Zarrilli kicked a 19-yd field goal to pull within four points, 7-3. The boot capped a 9 play 71 yd drive by The Pride. Following a fake punt in which Tom Bishop ran the ball 26 yards to put the football on the Hofstra 26 yd line, UNH's J.T. Wright caught 31 yd. pass from Santos to give UNH a 13-3 advantage at 14:52 of the second stanza following the missed PAT attempt. The TD catch capped a 5-play 51 yd drive. At 11:53 of the second quarter Santos threw another perfect 26 yd pass to the end zone, this time to tight end Scott Sicko and the Wildcats led 19-3 after the PAT was blocked. UNH drove the ball downfield quickly again and had third and goal on the 1 yd line. Santos and J.T. Wright connected for the second time in the contest at 5:46 of the second quarter. Following the PAT by Manning UNH was up 26-3. The scoring drive included 11 plays for 80 yds. In a tremendous play, senior free safety Jeff Pammer blocked a pass attempt into the air, made the interception and then returned the football 66 yds for a TD that gave the Wildcats a 33-3 advantage with 2:55 to play before the half. Santos turned in a stellar performance by halftime, completing 17 of 21 passes for 211 yds and three TDs.Hofstra then moved the ball into the UNH red xone, but sophomore defensive lineman T.J. Taylor stepped in and intercepted the ball on the UNH 18 yd line. UNH took a knee to end the first half. Hofstra started with the ball in the second stanza and fumbled on a hit by senior linebacker Husain Karim and a recovery by defensive back John Clements. Santos then threw a 47 yd bomb, once again to the end zone and LeVan and the Wildcats led 40-3 with 13:52 to go in the third quarter. Santos finished the game 19 of 23 for 262 yards, 4 passing TDs, 1 rushing TD and no interceptions. Leading the receivers with century mark was LeVan with 7 catches for 121 yds and a TD. The Wildcats will return to action on Sat., Oct. 27 vs. Rhode Island. Game time is at 12 p.m. and the contest can be seen live on NESN and on unhwildcats.tv. Tickets for the game are still available online at www.unhwildcats.com.