Widget host container component for a rapid application development tool

A widget host container serves as a component that may be added via a rapid application development tool, such as Oracle International Corporation's Application Development Framework. The rapid application development tool may be used to install the widget host container, for example, in a region of a user interaction environment, such as an application or a suite of user interactive applications, created by the rapid application development tool. If desired, one or more selection devices, such as a drop down menu, may be provided to select particular widgets for use and display. Features may be provided for organizing both personal and enterprise widgets. Security settings control access to web widgets, and an option to allow or restrict access to web widget display options in the container.

BACKGROUND OF THE INVENTION

A desktop widget is a small specialized graphical user interface (GUI) application that provides some visual information and/or easy access to frequently used functions such as clocks, calendars, news aggregators, calculators and desktop notes. A widget engine is a software service available to users for running and displaying desktop widgets on the desktop of a computer. Desktop widgets are different than web widgets. Web widgets are hosted remotely and run inside a web page. Web widgets allow anyone to create a website by embedding content or tools from one site onto a page of another site. In contrast, a desktop widget is a desktop-based mini-application that is hosted locally. A desktop widget shows discrete information and is often connected to the Internet to provide content.

One of the most popular desktop widgets is YAHOO! Widgets. YAHOO! Widgets provide an XML/JavaScript solution to building simple components for a person's desktop. These components, however, like all desktop widgets, have to be rendered by a proprietary YAHOO! widget engine installed on a user's desktop. Installing desktop widgets on a user's computer may result in clutter of a work computer's desktop with applications that are for personal use. In addition, such desktop widgets cannot currently be installed in an application or as part of a user interface because the desktop widgets require the proprietary widget engine to run, and the widget engine must be installed on the desktop.

From an enterprise perspective, there is no way to administrate desktop widgets as most desktop widgets, including YAHOO! Widgets, require a manual download to the desktop of the widget engine, and once a user has installed this application, the user can download any number of widgets the user chooses, including widgets that may contribute to the employee's efficiency, but also many widgets that are of a personal nature and which may reduce efficiency. Businesses that wish to develop or promote widgets that are useful to their employees or clients have to contend with the possibility that employees will take advantage of the presence of the desktop widget engine on their desktop to download non-business essential desktop widgets.

BRIEF SUMMARY OF THE INVENTION

In accordance with an embodiment, a widget host container is provided for hosting locally run widgets. The widget host container includes many of the functions of a desktop widget engine, but is included as part of the user interface component, and thus may be installed as part of an application or in a user interaction environment.

The widget host container serves as a component that may be added via a rapid application development tool, such as Oracle International Corporation's Application Development Framework. The rapid application development tool may be used to install the widget host container, for example, in a region of a user interaction environment, such as an application or a suite of user interactive applications, created by the rapid application development tool. If desired, multiple options may be provided in terms of regions to provide the widget host container. In addition, one or more selection devices, such as a drop down menu, may be provided to select particular locally hosted widgets for use and display. Tabbed pages may be provided on a display for the container for organizing both personal and enterprise widgets.

In accordance with an embodiment, an administrator may seed the widget host container with a specific widget or widgets and, if the administrator so chooses, may provide customization and preference options to users to manage their own widgets. Different users may be presented with different sets of widgets based upon their security clearance and/or profiles.

In an embodiment, the widget host container includes a parser, such as an XML interpreter, for interpreting a widget configuration file. The widget host container may also include a library containing code, such as JavaScript code, that performs actions requested by the interpreted widget configuration file. Alternatively, the library may map calls to code locally stored with the user interaction environment or stored remotely, such as at a centralized server.

If desired, toolbar controls may be provided for adding, hiding, or removing widgets from the display region of the widget host container component.

Other features of the invention will become apparent from the following detailed description when taken in conjunction with the drawings, in which:

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings, in which like reference numerals represent like parts throughout the several views,FIG. 1shows a prior art desktop widget environment20. The desktop widget environment20represents, for example, a YAHOO! Widget environment. Although some desktop widget environments may be different than shown, the basic components shown inFIG. 1are believed to be present in most prior art desktop widget environments.

The desktop widget environment20includes a widget engine22. For YAHOO! Widgets, the widget engine22is called KONFABULATOR. The widget engine22includes a compiler24and a page builder26. The widget engine22also includes a display component28.

For each desktop widget that is run in the desktop widget environment20, a configuration file30is provided. This configuration file includes configuration information such as controls (size of display, etc.). The configuration file may also specify actions the controls will take and events that a control may return. The configuration file may include calls to the Internet to retrieve web pages or RSS, or may interact with online scripts. JavaScript calls may be made, with related code maintained by the widget engine. Configuration files are well known and documented, and for YAHOO! Widgets, are called “KON” files.

In use, the widget engine22, and more specifically the compiler24, configures the configuration file30into a compiled widget32. This compiled widget32, in turn, is built into a page by the page builder26and is displayed by the display component28as a displayed desktop widget34. KONFABULATOR, for example, utilizes a JavaScript runtime environment combined with an XML interpreter. One or more widgets may be displayed by the display component28.

As described in the background section of this document, one problem with the desktop widget environment20shown inFIG. 1is that, once the widget engine22is installed on a user's desktop, an administrator cannot administrate what desktop widgets are downloaded and utilized by each of the users on a network. Desktop widgets may contribute to an employee's efficiency, but many widgets may do just the opposite: they may distract an employee from work tasks. In addition, display of desktop widgets on a user's desktop may result in unwanted clutter.

In accordance with an embodiment, a widget host container is provided that includes functions similar to a widget engine, such as the prior art widget engine22described above. The widget host container may be utilized, for example, as a graphical user interface component of a rapid application development tool. Rapid application development tools, such as a rapid application development tool40shown inFIG. 2, are known. In general, rapid application development tools, sometimes known as integrated development environments, utilize web application frameworks or other types of software frameworks to speed application development. Prototypes or templates are provided as easily-added building blocks for user interface modules and other components of an application or another user interaction environment.

An example of a rapid application development tool is Oracle International Corporation's Application Development Framework, also called the “ORACLE ADF.” ORACLE ADF is a commercial Java framework for creating enterprise applications and user interaction environments.

ORACLE ADF is based upon the model-view-controller architecture, which is well known and documented. This architecture isolates business logic (e.g., data) from user interface considerations, resulting in an application or user interaction environment where it is easier to modify either the visual appearance of a user interaction environment (e.g., an application or a suite of user interactive applications or windows) or the underlying business rules without affecting the other. In the model-view-controller architecture, the model represents the information (the data) of the application and the business rules used to manipulate that data, the view corresponds to the elements of the user interface such as text, check box items, and so forth, and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

The rapid application development tool40shown inFIG. 2is a simplified representation of the user interface for ORACLE ADF. The rapid application development tool40includes a model tree41having nodes42representing data for use in creating a user interaction environment, such as a user interaction environment50(FIG. 5). The user interaction environment50may be, for example, an application or a suite of user interactive interfaces.

The rapid application development tool40also includes a view controller tree43, which includes both the view and controller features of the model-view-controller architecture. Again, like the model tree41, the view controller tree43includes nodes44that may be utilized for creating a user interaction environment50.

The developer utilizes tools provided by the rapid application development tool40to create components46utilizing the model tree nodes42and the view controller nodes44. The model tree nodes42and the view controller nodes44are bound during this process. Nodes42,44may be selected for use via a wizard or other tool, or may be implemented using drag and drop or other methods. Each component may include several different options for display or function.

The components46may be utilized in development of an application or another user interaction environment50. The user interaction environment50and/or the components46are typically created within the working window45. The components46may be added, for example, via a wizard, using drag and drop methods, or utilizing other methods. During development of the components46, a developer may utilize a design view, in which components46are viewable as user interface modules, or a source view in which the source code for the components is viewable and editable.

Although ORACLE ADF is provided as an example, the widget host container component described herein may be utilized in other rapid application development tool environments. However, for ease of description, the example herein involves use of ORACLE ADF.

One of the components, for example the component461, of ORACLE ADF is a task flow component. A task flow is a ORACLE ADF component in which a developer defines an application task. The definition of the task includes the pages and logic that interact to allow the task flow to complete the task. At design time, the pages and page fragments that make up a task are added to a task flow as activities; in the cases of pages and page fragments they are view activities. So, when users navigate from one page to another within a task flow, they are transitioning from one activity to another. Activities can be considered the building blocks of the task flows. There are other activities besides view activities. ORACLE ADF task flows are well known and documented, so their structures are not described in detail here.

FIG. 3shows an example of a user interaction environment50developed by the rapid application development tool40. The user interaction environment50in the example shown in the figure includes a header52, a sidebar54, and an application window56. Each of these regions of the user interaction environment50may be formed by the rapid application development tool40. The user interaction environment50is a suite of interactive applications, and serves as the screen view provided to each of the users on a network. The application window56hosts a current application used by a user. The sidebar54may include a collection of the components46, and the header52may include a collection of components and/or links. The application window56may include one or more of the components46. The user interaction environment50is but one example of a layout of a user interaction environment that may be provided by the rapid application development tool40.

In embodiments, a widget host container may be utilized in any of the regions of the user interaction environment50, including the header52and the sidebar54, or specific regions within each of these areas. For example, for an embodiment where a task flow is utilized, the task flow may be placed in an upper portion of the sidebar54of the user interaction environment50.

In accordance with an embodiment, as shown inFIG. 4, the sidebar54includes a widget user interface component60having a drop-down menu62and several widgets64displayed. The drop-down menu62permits a user to select particular widgets64for display. This widget host container component60may be one of the components46of the rapid application development tool40shown inFIG. 2

In use, the widget host container component60is created by a component designer for the rapid application development tool40. In the example shown inFIG. 5, the widget host container component60includes a parser72, a library74, and a page composer76. The parser72, the library74, and the page composer76act to generate a page fragment77that is ready for display in the user interface60.

FIG. 8shows a representation of a widget configuration file90for use with the widget host container component60in accordance with an embodiment. The widget configuration file90includes code92that defines an activity, such as interaction with a user. In the embodiment in the drawings, the code is JavaScript. The widget90may include elements designated by, for example, XML tags94. Some of the elements may include HTML96to define a part of a page for the web widget90.

The component designer associates the widget host container component60with one or more widget configuration files90. To this end, a database80may be provided for storing the widget configuration files90. This database80may be maintained, for example, on a server that is associated with the user interaction environment50. If desired, the widget configuration files90may be created by a developer. In an embodiment, the widget configuration files90, when instantiated, are hosted locally by the widget host container component60. Thus, the widgets utilized with the widget host container component60are more like desktop widgets than web widgets, albeit running in the container component60instead of on a desktop. To this end, the widgets for use in container component60are locally hosted widgets, as opposed to web widgets, which are typically remotely hosted.

The parser72, the library74, and the page composer76are used to generate a page fragment77(FIG. 5) from one of the widget configuration files90for display in the user interface component60. The page fragment77represents the display of the widgets64in the user interface component60, as shown inFIG. 4.FIG. 6is a flow diagram representing steps for generating a widget page77in accordance with an embodiment. Beginning at step600, the configuration file90is parsed, for example by the parser72. The parser72, which may be, for example, an XML interpreter, interprets the tags within the configuration file90. As described above, the configuration file may include HTML96for the page composer76to build a page in the user interface60.

At step602, the widget host container component60accesses code utilized by the configuration file90. As part of the interpretation of the configuration file90, calls to code, such as JavaScript code, may be parsed. To this end, the library72may include code, such as JavaScript, that performs the functions and action of the code referenced in the configuration file90. The library72may locally store the code, or may include mapping to code stored somewhere remote from the library72, for example in the database80or a separate database. This code may be maintained with the widget host container component60or may be stored on a server, for example.

At step604, the page fragment77is built for the widget, for example by the page composer76. The parser72and the library74may, for example, develop the page fragment77in accordance with an object model, such as the Document Object Model. This page fragment77will be accessed and displayed by the user interface component60.

If configuration files90are stored in the database80, then the parser72, the library74, and the page composer76may be included in the widget host container component60, and the page fragments77may be built locally. Alternatively, built page fragments77may be stored in the database80, and the parser72, the library74, and the page composer76may be used to generate the page fragments, but are not necessarily used locally. The stored page fragments77may be associated with the user interaction environment50, for example stored in the database80. Ultimately, once a page fragment77is built and instantiated locally in the user interface60, then the configuration file30, the parser72, the library74, and the page composer76should not be needed again for that widget.

As part of the features of the widget host container component60, a component designer may define what widgets are available for use with the widget host container component60. To this end, the widget host container component60may include a selector component78(FIG. 5) for selecting widget configuration files90for use with the user interaction environment50. In addition, a privileges component79may be provided so that a developer (i.e., a person utilizing the rapid application development tool40to build the user interaction environment50) or administrator may limit the widgets available to specific users of the user interaction environment50. These limitations may be set, for example, via the selector component78, by widgets or widget pages that are actually available at the database80, and/or by security or privileges set by the developer or an administrator via the privileges component79.

FIG. 7is a flow chart representing steps for building an application or other user interaction environment including the widget host container component60in accordance with an embodiment. In step700, a developer adds the widget host container component60to the user interaction environment50, for example by dragging and dropping a task flow including the widget host container component60into a region of the side bar54. At step702, the developer selects, for example via the selector component78, one or more widgets that may be used with the widget host container component60. These widgets are available, for example, via the Internet, or may be provided by the designer of the widget host container component60. At step704, the developer may select how to display the selected widgets, for example via the widget selector component78. As examples, a developer may select to require display of all of the widgets that have been selected, or may allow selection by a user of particular widgets via the drop-down menu62. At step706, if desired, security and/or privileges may be applied to the widget host container component60, for example via the privileges component79, so that different users may have different selections of widgets available. Alternatively, the developer may provide or turn on a feature for an administrator of the user interaction environment50to set security and or privileges for widgets.

During use, the selected widgets64are displayed by the widget host container component60at the desktop user interface60. The page fragments77are accessed and displayed in the user interface60. If desired, tabs or other features may be provided for organizing the widgets.

The widget host container component60provides an enterprise solution for making widgets, similar to desktop widgets, available on user's computers throughout a network. The widget host container component60allows use of widgets in an enterprise user interaction environment. A developer or administrator may limit particular widgets based upon security and/or privileges. The developer may choose to display the widgets in multiple different regions of the user interaction environment50. A user may select one or more of the widgets for use via the drop-down menu62or other selection device provided by the developer. The widgets may interact with data available to the user interaction environment50. This data may be, for example, business data available on a network.