1. Field of the Invention
The present invention relates generally to methods for programming a machine to perform data processing, and in one aspect to methods for programming a machine to perform specific data processing tasks described in a simplified manner.
2. Description of the Related Art
Today, most types of software applications are installed directly on a user's computer. Examples of such applications include the Microsoft™ Word™, Adobe™ Photoshop™, and Intuit™ Quicken™ computer programs. A user of such an application generally is limited to using that application on the computers on which it has been installed. This limitation is problematic if a user is traveling and does not have physical access to the computer on which an application is installed. Furthermore, updating these applications to add new features or fix defects requires installation of updates directly on the user's computer, which is often a time-consuming process.
Web applications, also referred to herein as browser-based applications, solve such usability and installation problems by using a web browser, e.g. Microsoft Internet Explorer™ or Mozilla Firefox™, and a web server, e.g. Apache™ or Microsoft™ Internet Information Services™. An application can be divided into at least two main parts: a user interface, which is presented to a user and interacts with the user, and business logic, which performs the tasks required of the application, in accordance with user input received from the user interface. The web browser runs the user interface. The web server provides the user interface to the web browser and runs the business logic, possibly in cooperation with other servers such as an application server, e.g. JBoss™ or BEA™ WebLogic™, and a database server, e.g. Oracle™. The web application need not be installed directly on the user's computer. The term server or web server here refers to software executed on a computer, also referred to generally in the field as a server platform.
A web browser is a type of specialized software application, typically installed directly on the user's computer, which allows a user to view and interact with web pages. Web pages are documents, typically in HyperText Markup Language (HTML) format that the web browser retrieves from a web server computer via a network, using a protocol such as the HyperText Transfer Protocol (HTTP). Web pages may include software code in a programming language such as JavaScript™ which will be executed by the web browser when the page is retrieved. A web application includes a user-interface component that is loaded as part of a web page by a browser via a network connection. A web application's user interface may be implemented as a web page using HTML and JavaScript™. A browser-equipped computer, therefore, uses a network connection to permit a user to access a web application running on a remote server, for example. Furthermore, web applications can be updated at any time by installing the update on the server.
Computer software applications are often required to perform operations that are specific to a particular user or organization. For example, a software application may be used to in a hospital to request clinical tests. The software application may include a set of data fields for which a user provides data values, such as a patient name and a test name. A particular hospital may also require a patient medical record number in a format defined by that hospital. In general, the set of data fields, and actions to be taken after data values have been provided, are dependent on the needs of the hospital, and may change over time. Therefore there is a need for customization of software to meet specific requirements. Customization of software may include developing new software or modifying existing software. Customization can be done by a programmer using a programming language such as C++, Java, or BASIC. However, the use of such languages often requires substantial time and effort, as well as specialized knowledge of the programming language, so such customization by programming can be expensive. Rapid Application Development (RAD) tools address these problems by simplifying programming tasks. A typical RAD tool is software that includes a graphical user interface for laying out application user interfaces and defining application behaviors in terms of predefined actions such as data entry and database access. A RAD tool may present a list of predefined behaviors or actions from which a user can choose when creating or extending an application. RAD tools are generally easier to learn and use than conventional programming-language based approaches for developing applications, and can shorten the time required to develop applications. Existing RAD tools include Borland Delphi™, Microsoft Visual Basic™, and Macromedia/Adobe ColdFusion™, which can be used to develop a wide range of applications, but often require some programming. RAD tools such as Intuit QuickBase and Microsoft InfoPath can be used to develop applications that involve filling out data forms and accessing databases.
There is a need for non-programmers to design, develop, and deploy simple to complex, composite and monolithic applications in the business world today. Application development is a costly, time consuming, and risky proposition for even capable engineering organizations, let alone business analysts and other non-technical staff. Few organizations have the resources to use complex development tools and deployment environments to build and deploy applications. This engineering capability void has fostered a large and thriving software industry as known today. Even so, packaged software applications are expensive to purchase and even more expensive to install, configure and maintain. A new breed of Software As A Service, (SAAS,) vendors have evolved to deliver complex software as a service to further eliminate complexity and reduce costs to leverage software application benefits. Even with SAAS vendors providing robust pre-built applications, only a small percentage of business software application requirements are met and hence, the need for both applications and infrastructure that is aimed at business analysts and programmers to design, develop and deploy applications quickly and efficiently.
Several of the RAD tools described above provide support for creating web applications. Delphi™, Visual Basic™, and ColdFusion™ simplify the development of web applications created using programming languages. That is, those tools simplify the creation of user interfaces by providing graphical user interface builder tools that can be easily connected to business logic implemented in a programming language, but it is still necessary to write code in a programming language for some portions of the application, such as the business logic. QuickBase™ provides for rapid development of forms-based web applications using a graphical user interface. Furthermore, QuickBase itself is a web application, which means that it allows web applications to be developed using the same web application model in which the applications will be deployed. That is, users of QuickBase can develop applications on any computer running a web browser, without directly installing QuickBase software on their own computer. QuickBase applications may also be hosted on web servers provided by a software vendor, for example, Intuit, so that users are not required to provide a web server to host QuickBase applications they develop.
InfoPath™ from Microsoft™ provides for rapid development of forms. InfoPath forms can optionally be made available as web applications, but the InfoPath form designer itself is not a web application and must be installed directly on a user's computer. Furthermore, InfoPath depends on other Microsoft products such as Internet Explorer™ and does not work with browsers from other vendors, such as Mozilla Firefox™. Therefore InfoPath forms can only be accessed from computers on which InfoPath™ and related Microsoft™ products are installed.
Existing RAD tools do not combine the benefits of web applications with features such as customizable processing in a scripting language, linkage with external data sources such as databases, and linkage to web services. We have recognized that it would be desirable to have an easy-to-use RAD tool which is itself a web application, and which allows a user to quickly develop and customize web-based data processing applications that can include data input, validation, processing, and linkage with web services. Such a RAD tool could be used to quickly and efficiently develop and customize applications using any computer that has a standard web browser and access to the Internet. Furthermore, web applications typically require complex business logic for their activities. This logic is typically written in strongly typed languages and the logic requires recompilation and redeployment. It would be desirable to provide a RAD tool with a scripting language which can change or extend the behavior of web applications without the additional overhead of recompilation or redeployment.
Existing Web-based RAD tools do not provide a single unified interface and environment for building a web application that includes a user interface linked to persistent data stored in a database. Existing Web-based RAD tools disadvantageously use a multi-step process that starts at the level of individual data elements, and expect the user to perform a series of steps to define a user interface linked to persistent data. These steps typically include defining a field, defining an object, defining a container, linking the objects, defining a user interface, and linking the user interface to the objects and fields, all of which are complex and time-consuming.
In general, in a first aspect, the invention features a computer enabled method of creating a software application. The method includes the acts of providing a user interface for designing the software application on a web browser, defining aspects of the application via the web browser using the user interface, and transmitting the defined aspects to a server over a computer network to create a web-based software application. Embodiments of the invention may include one or more of the following features. The method of creating a software application may include the acts of providing a set of components on the web browser and implementing aspects of the application using the components. The method may include the steps of providing a library on the browser and using the library as an intermediary between the defined aspects at the browser and the server. The computer network may include the Internet. The method may include, at the server, the steps of rendering a representation of the application from the transmitted defined aspects, retrieving data associated with the application from a storage, and transmitting the representation and retrieved data to a client. The method may include, at the client, the act of executing the representation and data on a web browser. The method may include the acts of providing a library on the web browser of the client and using the library as an intermediary between the web browser of the client and the server. The method may include the acts of tracking multiple versions of the software application, maintaining each version as compatible with prior versions of the software application, and allowing multiple of the versions to be active at the same time.
In a second aspect, the invention features a computer enabled method of providing a software application, including the acts of receiving at a server over a computer network from a first client web browser a software application including defined aspects of the application, rendering a representation of the application from the received defined aspects, retrieving data associated with the application from a storage, and transmitting the representation and retrieved data to a second client. Embodiments of the invention may include one or more of the following features. In the method of providing a software application, the computer network may include the Internet. The method of providing a software application may include, at the second client, the steps of providing a web browser and providing a user interface to a user on the web browser from the received representation and data. The method of providing a software application may include, at the second client, the acts of: providing a library on the browser and using the library as an intermediary between the browser and the server. The method of providing a software application may include the acts of providing a user interface on the web browser at the first client for designing the software application, defining the aspects of the application using the user interface, and transmitting the defined aspects to the server over the computer network. The method of providing a software application may include the acts of tracking a plurality of versions of the software application, maintaining each version as compatible with prior versions of the software application, and allowing a plurality of the versions to be active at the same time.
In general, in a third aspect, the invention features a computer enabled method of providing a software application, including the acts of receiving over a computer network aspects of an application from a server, executing the application on a web browser, providing a user interface, and allowing use of the application via the user interface.
In general, in a fourth aspect, the invention features a client to be executed on a computer. The client includes a user interface adapted for designing a software application on a web browser and an application definition module which defines aspects of the software application via the web browser using the user interface. Furthermore, the web browser may transmit the defined aspects to a server over a computer network to create the software application. Embodiments of the invention may include one or more of the following features. Multiple components may be on the web browser, and some of the aspects of the application may be implemented using the components. The client may include a library on the browser, and the library may be used as an intermediary between the defined aspects at the browser and the server. The computer network may include the Internet.
In general, in a fifth aspect, the invention features an application server to be executed on a computer. The application server includes an application definition module for receiving over a computer network from a first client web browser a software application, including defined aspects of the application, and rendering a representation of the application from the received defined aspects. The application server also includes a service for retrieving data associated with the application from a storage, and an application player module for transmitting the representation and retrieved data to a second client. The application server may include, at the server, a version control for tracking multiple versions of the software application, maintaining each version as compatible with prior versions of the software application, and allowing multiple versions to be active at the same time.
In general, in a sixth aspect, the invention features a player client to be executed on a computer. The player client includes a definition module for receiving over a computer network aspects of an application from a server, a data module for receiving over the computer network from the server data relating to the application, and a user interface for executing the application on a web browser. Embodiments of the invention may include one or more of the following features. The player client may use a library on the browser as an intermediary between defined aspects of the application and the server.
In general, in a seventh aspect, the invention features a method of running an application program in a web browser, including the acts of providing at least one client computer and one server computer in communication with the network, executing a web browser on the client computer, executing a client portion of the application program on the web browser, wherein the client portion presents a runtime user interface according to an application definition. The application definition includes a component described by a component definition, the component includes a name and a data value, and the client portion receives the data value from a user. The method of running an application program further includes the step of executing a server portion of the application program on the server computer, wherein the server portion receives the data value from the client portion and stores the data value in a database, as specified by the application definition. Embodiments of the invention may include one or more of the following features. The component may include a link, the link may refer to a web service, and the client program may receive the data value from the web service in response to a user action. The component may include a script operable to execute in response to an application event, and the script may perform calculations based on a data value associated with another component. The script may set a data value associated with another component. The component may be associated with a row of a table component.
In general, in an eighth aspect, the invention features a method for designing an application program in a web browser, including the acts of providing at least one client computer and one server computer in communication with the network, executing a web browser on the client computer, and executing a designer program on the web browser. The the designer program presents a user interface that includes a workspace upon which a user can place an interface component at a specified location, the interface component being associated with a component data value. The designer program creates an application definition, the application definition describing properties of the interface component, including an association between the component data value and a corresponding component data value in a database.
Embodiments of the invention may include one or more of the following features. The component may be associated with a link, and the designer program may receive a Uniform Resource Locator associated with the link from a user. The component may be associated with a computer program code script, the designer program may receive the computer program code script from a user, and the computer program code script may perform calculations based on the value of another component. The computer program code script may set the value of another component. The user may place a table component upon the workspace. The table component may include a table header row having at least one column definition and a table detail row having at least one column corresponding to the at least one column definition, and the column may be associated with a detail component having a detail data value. The application definition may describe the table component and an association between the at least one detail data value and a corresponding detail column in a database.
a is an illustrative drawing of an enterprise application design and deployment system according to one embodiment of the invention.
b is an illustrative drawing of a browser-based application according to one embodiment of the invention.
a and 2b are illustrative drawings of application definitions according to one embodiment of the invention.
a and 4b are illustrative drawings an application definition format according to one embodiment of the invention.
a,
5
b, and 5c are illustrative drawings of application definitions according to one embodiment of the invention.
a,
6
b, and 6c are illustrative drawings of an application data format and application data values according to one embodiment of the invention.
a-7i are illustrative drawings of an Application Designer and Application Player user interfaces, according to one embodiment of the invention.
a and 10b are illustrative drawings of flowcharts of a method of loading an existing application according to one embodiment of the invention.
a is an illustrative drawing of an application including a mode and a version number according to one embodiment of the invention.
b is an illustrative drawing of application mode transitions according to one embedment of the invention.
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
a is an illustrative drawing of an enterprise application design and deployment system according to one embodiment of the invention. A user 100 interacts with the Designer UI (user interface) 102 to design an application, e.g. a data input form, and a user 118, which may be the same user as user 100, or may be a different user, interacts with a Player UI (user interface) 114 to execute the application. The Designer UI and Player UI are software programs that are executed by a web browser running on a computer (shown in
b is an illustrative drawing of a browser-based application according to one embodiment of the invention. A web browser 132 executes a Player UI 134, which in turns executes an application 135. The Player UI 134 presents the application 135 to a user 130 via the web browser 132. The application 135 includes at least one component 136, which represents a user interface element such as a text box or a web link. The component 136 includes a name 138, which uniquely identifies the component. The component 136 is accessible by the name 138 in a Document Object Model associated with the web browser 132 in scripting languages, e.g. JavaScript™ or the like. The user 130 can provide computer program code as a script 143, which is associated with the component 136, for performing calculations based on the data value 142 in response to events, such as a user changing the data value 142. A script 143 can also set the data value 142. The component 136 also includes properties 140, which describe the component, e.g., the location of the component on a web page, and the type of component, e.g. a text box or link component. The properties 140 may include the name 138. The component 136 also includes a data value 142, e.g. a text string or numeric value, which can be specified by a user via the Player UI 134. The data value 142 is stored in a database 144 in a database column specified in the properties 140. The component 136 also includes a link 142, which has an associated Uniform Resource Locator (URL) that can refer to another application 146, or a web page 148, or a web service 150. The link 142 may send or receive the data value 142 to or from the application 146, the web page 148, or the web service 150, in response, for example, to input from the user 130. A description of the component 136, including the properties 140, is stored in the application definition 108 of
a is an illustrative drawing of an application definition according to one embodiment of the invention. An application 200 may include at least one StandardArea 202. A StandardArea 202 includes area properties 240 and at least one component 204. There is a second type of area, called a table area, which is shown as TableArea 203 in
A component 204 is a user interface element of a specific type. The component 204 may be a Label, Text Box, Text Area, Radio Button, Check Box, Select List (e.g. a drop-down list), File Attachment, Button, Image, or link. Each component has associated properties. The component types and the properties associated with each component type are descrobed in the table below.
The component 204 has component properties 208. If the component 204 is a data-holding component, e.g., a TextBox, TextArea, Select List, RadioButton, CheckBox, or File Attachment, then the component 204 has a value 206. The component properties 208 include a name property, which uniquely identifies the component within the area 204, a type property, e.g. label or text box, a label property, the value of which is displayed in the user interface for some component types, such as the label component type. The component properties 208 also include rowindex and colindex properties, which indicate the position of the component within the area, a hidden property, which indicates whether the component is to be displayed or hidden in the Player UI, and a datalinkage property, which indicates a source of values for the component, e.g. a database column containing values for a selection list, a datatype property, which indicates the permitted type of the value 206, and a required property, which indicates whether a value is required for the component 204.
The component properties 208 further include a dataset property, which may specify a database column in which the component's value 206 is stored. Because of the differences in data representations between the web browser's HTML-based data model, the Java object model used by the server, and the relational database model in which data is stored persistently, the XML application definition establishes a mapping between application data and database data, based on a component naming convention in which a unique name is assigned to each component. A DATASET attribute is also assigned to each component. The DATASET attribute specifies a database table and column name and thereby binds the component's value to a database column. The application data value of the component is stored in the specified database column. Multiple instances of application data are stored as separate database rows, so that each instance of application data, e.g. each Radiology Order Request instance associated with a Radiology Order Request application, is stored as a separate row in the database. The unique component name is generated by concatenating the names of enclosing components, such as areas and tables, with the component name and numeric counter values as described below.
Application definitions are specified using the Extensible Markup Language (XML). An XML document structure 250, shows how an application 200 that includes the StandardArea 202 can be defined using XML. The XML document structure has XML elements that correspond to the elements of the StandardArea 202. Specifically, the XML structure has a Form element 255, an Area element 256, and at least one FormComponent 257.
The Area element 256 and the Form element 255 enclose the FormComponent(s) 257, as shown by an Area element end marker 258 and a Form element end marker 259. The Form element 255 has a name attribute, which is assigned a value such as the name of the application. The Area element 256 includes four attributes: a name attribute, and label, rows, and cols attributes. The name attribute specifies a name for the area, and gets its value from an area name property 205 of Area properties 240. The area name property 205 is assigned a value, e.g. “area—0”, by a string concatenation method based a counter value, e.g. 0, for the first area, that is incremented for each area in the Application 200. The value of the area name property 205 is assigned, for example, when the StandardArea 202 is added to the application. The label attribute specifies a name to be displayed for the area in the user interface, and gets its value from the dispalyname property of Area properties 240. The rows and cols attributes specify the number of rows and columns, respectively, in the area, and get their values from the rowcount and colcount properties, respectively, of Area properties 240. The FormComponent element 257 is an XML representation of the user interface component 204 and includes attributes, such as name and type attributes, which are assigned values from corresponding component properties 208 of the component 204, e.g. name and type properties, respectively. A component name property 209 is assigned a value, e.g. “comp_area—0—0—0”, by a string concatenation method based on the type of component, e.g. “comp_”, the name of the enclosing area, e.g. “area—0”, and a counter value that is incremented for each component 204 in the application, e.g. 0 for the first component. The value of the component name property 209 is assigned, for example, when the StandardArea 202 is added to the application. Generally, the name of a component in a StandardArea is generated by the following expression:
<ComponentType>+“_”+<AreaName>+“_”+<CounterValue>
where ComponentType is a string that corresponds to the type of the component, e.g. “comp” for data input components such as selection boxes, or “lbl” for label components, AreaName is the name of the enclosing Area, and CounterValue is a number that uniquely identifies the component within the enclosing Area. The counter values are assigned based on the number of components of the same type that have been previously processed in the enclosing Area. All non-alphanumeric characters in the name are replaced with underscores (_) when the component name is generated.
b is an illustrative drawing of an application definition according to one embodiment of the invention. An application 200 may contain at least one table area 203, which defines a table of rows and columns that will be presented to a user in the Application Player. A table area 203 includes area properties 240 and at least one TableComponent 249. A TableComponent 249 includes a TableHeadRow 241, a TableDetailRow 243, and zero or more TableFootRows 246. The TableHeadRow 241 describes the names, sizes, and positions of columns in the table. The TableHeadRow 241 includes zero or more column definitions 251. Each column definition 251 has column properties 241, which include a column name property 252, a width property that specifies the width of the column, and a colindex property that specifies the position of the column in the table.
A column name property 252 is assigned a value, e.g. “tcol_hdr_table_area—1—0”, by concatenating the type of the table row, e.g. “tcol_hdr” for a table header row, with the name of the enclosing TableComponent 249, e.g. “table_area—1” and a counter value, e.g. 0, that is incremented for each column 251 in the application. The value of the component name property 209 is assigned, for example, when the StandardArea 202 is added to the application. Generally, the name of a component in a TableArea is generated by the following concatenation expression:
<RowType>+“_”+<AreaName>+“_”+<TableName>+“_+<TableColumnName>+“_”+<FormComponentName>+“_”+<CounterValue>
where RowType is a string based on the type of row. Specifically, RowType is set to tcol_hdr for header rows, dcol_dtl for detail rows, and fcol_ftr<counter> for footer rows, which have an associated counter value because there can be multiple footer rows), AreaName is the name of the enclosing Area, and CounterValue is a number that uniquely identifies the component within the enclosing Area. The counter values are assigned based on the number of components of the same type that have been previously processed in the enclosing Area. All non-alphanumeric characters in the name are replaced with underscores (_) when the component name is generated.
Table values are stored in detail rows, which are described by a TableDetailRow 243 that has zero or more columns 244. Each column has zero or more components 245 which store data values associated with column. The TableDetailRow is associated with a database table, e.g., a process_detail table (described below with reference to
An XML document structure 261 shows how an application 200 that includes the TableArea 203 can be described using XML. The XML document structure 261 has XML elements that correspond to the elements of the TableArea 203. Specifically, the XML structure 261 has a Form element 262, which corresponds to the Application 200. The Form element 262 encloses an Area element 263, which corresponds to the TableArea 203 and encloses at least one TableComponent 264. The Area element 263 has a name property, which is assigned to the value of the name property 205 of theTableArea 203. The name property 205 of the TableArea 203 is assigned a value based on a concatenation method as described above. There is one TableComponent 264 element for each TableComponent 249 object of the Application 200. Each TableComponent 264 element has attributes, which are assigned values from corresponding column properties 242 of the column 251, e.g. name, width, and colindex properties. The TableComponent element 264 encloses a TableHeadRow element 265, a TableDetail row 268, and zero or more TableFootRows (not shown). A TableHeadRow element 265 encloses zero or more TableColumns 266, which correspond to the columns 251 of the application 200. Each TableColumn element 266 has XML attributes with the same names and values as the properties 242 of the column 251. The TableDetailRow element 268 similarly corresponds to the TableDetailRow 243 of the application 200 and encloses zero or more TableColumn elements 269 corresponding to the columns 244 of the application. Table detail rows can contain components such as text boxes, so the TableColumn elements 269 of the TableDetailRow 268 include zero or more FormComponent elements 270 that describe components 245 of the application 200. The FormComponent elements 270 are of the same form as the FormComponent elements 257 of
An application can be defined in a Web browser using client components implemented in a programming language, e.g. JavaScript, to create a representation of the application in terms of an object model. The object model includes objects such as an application object that has an array of area objects with properties, an area object that has an array of component objects, including basic components such as labels and text boxes with their properties, as well as table components. The table component object has an array of row objects, including a table head row object and a table detail row object that has an array of column objects, each of which has an array of component objects. A table foot row object would be similar to the table detail row object. The client components are also able to traverse the object in the object model to generate an XML application definition.
An XML application definition is generated by traversing the objects in the object model, e.g. by starting at the application object, looping through the application's area objects, generating the appropriate XML element begin marker for each area object, e.g. <Area> as shown in
a and 4b illustrate a schema describing a format for an application definition according to one embodiment of the invention. The schema may be, for example, an XML Schema describing the format of an XML document that represents an application. An application is stored, e.g. in a database, as an XML document that conforms to a Form schema 410. With reference to
A FormComponent 420 represents a component, e.g. a Text Box, and has attributes, including a name, a dispalyname, a type, a datatype, a required flag, a keyfield, a readonly flag, a defaultvalue, a rowindex which specifies the vertical position of the FormComponent 420 as a row number on an enclosing Area's grid, a colindex which specifies the vertical position of the FormComponent 420 as a column number on the enclosing Area's grid, a hidden flag, a datacolumn, which specifies a database column in which the value of the FormComponent is stored, a datalookup which specifies a database table from which a list of possible values for the FormComponent can be retrieved. A FormComponent 420 may include a FormComponentList, which may include one or more FormComponents 420. Note that the FormComponent definition is recursive and allows a FormComponentList to include multiple FormComponents. A FormComponent 420 may also include a BehaviorList 430.
A BehaviorList 430 may include Behaviors. A Behavior 435 represents executable code and has properties, including a name, an event, which may specify a type of event for which the behavior will be invoked, e.g. onchange, onClick, and the like, and a category. A Behavior 435 includes a Code element. The Code element includes code, e.g., JavaScript, which implements an event handler. The event handler will be called by the Player UI when a specific event occurs for the component, e.g. JavaScript code that is called when the component's value changes.
With reference to
a,
5
b, and 5c are illustrative drawings of application definitions according to one embodiment of the invention.
A Patient Name form component 526 describes the Patient Name label, and has properties that include a name, comp_area_0_1_0, a type, “LABEL”, and a label, “Patient Name:”. A Patient Name input form component 528 has a name, select_3, a type, “SELECT”, i.e. selection list, a datalookup, “CORE/$CID/USER”, which indicates that the list of values for the selection list will be loaded from the USER column of the $CID database, a dataset, “process_master/sc1”, which indicates that a value selected by the user will be stored in the “sc1” column of the process_master database table. The rowindex and colindex properties of the Form Component 528 indicate that the component is to be placed in the second column of the second row in the Area 520.
b illustrates a tree-representation of an application definition according to one embodiment of the invention. The tree shown in
c is an illustrative drawing of an application definition according to one embodiment of the invention. The application definition 540 is a text document in Extensible Markup Language (XML) format and includes nested elements definitions. An Area element 540 defines the area, and corresponds to the Area component 520 of
a illustrates application data 600, which includes a list of name-value pairs 602 corresponding to data values provided a user for an application according to one embodiment of the invention. With reference to
b illustrates example application data according to one embodiment of the invention. The example application data 604 includes an example date value 608, with the name date_1 and the value “4/33/2005”, and an example selection list value 610, with the name “select—3” and the value John J. Smith”. These application data values correspond to the values provided in data input component 308 and patient name input component 310, respectively.
c illustrates an example database table containing application data according to one embodiment of the invention. Database table 512, e.g. a table named process_detail stored in the Database 110 of
a is an illustrative drawing of an Application Designer user interface (UI) according to one embodiment of the invention. The Application Designer user interface (UI) 701 corresponds to the Designer UI 102 of
Once a component has been placed on the workspace, the user can set properties of the component to define specific behaviors, such as default values, table headings, mappings between controls and a database, and mappings between controls and web services. The workspace 702 includes a graphical representation of an example application definition that is being constructed by a user. In one embodiment, the application definition includes a data field 703 in which the user will enter data when the application is run in the Player. The data field 703 is associated with a label 704, which provides a textual description of the data field to a user. The workspace also includes an area 706 and a table area 708. The area 706 provides for grouping and positioning the locations of other fields, and contains the field 703 and the label 704. The table 708 includes a header row and five columns, named COL_0 through COL_4.
Palettes such as palette 712 shown in
c is an illustrative drawing of an Application Designer user interface (UI) according to one embodiment of the invention. The Application Designer user interface 701 includes a Control Properties interface 730, which allows a user to view and set properties of a selected component 731, which is a table column in this example. The table column's properties shown in the Control Properties interface 730 include a column label, a column width, and a component name. A user can change the values a property by entering a new value for the property. The Control Properties interface 730 also includes a Formula Builder button 735 and an Action Builder button 736. All Designer objects have unique properties. The properties for a numeric field have possible calculations while a drop down list may have a data source to populate the list of variables. The Control Properties interface 730 displays the properties available for the selected component type.
d and 7e are illustrative drawings of an Action Builder user interface according to one embodiment of the invention. The Action Builder 740 allows a user to associate one or more actions with each component of the application. Actions include event handlers and custom functions. Event handlers are functions implemented in a programming language, e.g., JavaScript, which are called by the Player UI when associated events occur, e.g. when a user changes a component's value. Custom functions are functions implemented in a programming language, e.g. JavaScript, which can be called by event handlers and by other custom functions.
The Action Builder 740 allows the user to implement event handlers and custom functions by writing code in a programming language such as JavaScript The Action Builder 740 is displayed by the Application Designer user interface in response to a user request, e.g. in response to a user pressing the Action Builder button 736 of
The Action Builder 740 has a Select Function option 744 which a user can use to create create a custom function. The user can provide a custom function name 746, which will identify the custom function, and will also be the name by which the custom function is invoked from JavaScript. Then a user can then use a code editor 749 to write JavaScript code 748 that will be called when the custom function is invoked. In the example of
The Player UI executes actions and evaluates formulas in response to events that are associated with user interface components such as buttons and tables. Events include user interface events, such as onClick, which occurs when the user has clicked on a table, or onchange, which occurs when a data value changes. The user interface event types include onBlur, onchange, onClick, onDoubleClick, and onMouseOver. Additional events are available for tables, such as onRowAdded. The event types are described in the table below.
An event handler is a function implemented by code in a programming language, e.g. JavaScript. A user defines an event handler by providing implementation code for an associated event type. The event handler is called by the Player UI when an event of the associated type occurs. To define an event handler, a user first selects a component of the application in an object selection box 745. In the example of
The Action Builder 740 includes a data element list 741, a function list 742, and a code editor 749. The data element list 741 is a list of the application's components. The data element list 741 has an entry corresponding to each area in the application, e.g. Area 1. Nested below each area entry is a list of the components in that area entry, e.g. text_area_1_1, text_area_1_3, and so on. The data element list 741 corresponds to a Document Object Model (not shown) associated with the application. The function list 742 includes user-defined functions, which are sometimes referred to herein as custom functions, and a set of commonly-used functions such as validateZipCode and SUM.
The code editor 749 allows a user to create and modify JavaScript implementation code 748 associated with a specified event 747, e.g. onClick, of a specified object 745, e.g., text_area_3_2, or with or a specified custom function 746, e.g. customFunction. The , JavaScript implementation code 748 associated with an event 747 of a specified object 745 will be called by the Player UI when the event occurs, e.g. when the user clicks on the specified object.
The JavaScript implementation code 748 for event handlers and custom functions can refer to any component of the application using JavaScript variables that are provided by the Document Object Model. A JavaScript variable is provided for each component of the application, and the variable has a name of the $<component>, where <component> is the name of the component. These component variables allow user-provided JavaScript code to read, write, and control other components. JavaScript code can get and set the value of a data-holding component, e.g., a TextBox, TextArea, Select List, Radio Button, CheckBox, or File Attachment by referring to a variable named $<component>.value.
The Action Builder 740 allows a user to select components from the Data Elements list 741 using, for example, a mouse pointer. When a component has been selected, the Action Builder 740 inserts a JavaScript variable name corresponding to the selected component into the code editor 749 at a current cursor position (not shown), so that the variable name becomes part of the JavaScript implementation code 748.
The JavaScript implementation code for custom functions and event handlers is stored in the XML application definition. In particular, the JavaScript code associated with a component is stored in a Behavior XML element of a BehaviorList element associated with the component. For example, an the JavaScript code for an onRowAdded event handler associated with a TableComponent would be stored as a Code element associated with a Behavior element, which is in turn associated with a BehaviorList element, which is associated with the TableComponent.
A link is a component that refers to an object such as an application or web page. The object may be located on a server specified by the link. The reference may be, for example, a Uniform Resource Locator (URL) that refers to a value on a web server. A Link can be associated with a Button component or a Link component.
h is an illustrative drawing of a Link Builder according to one embodiment of the invention. The Application Designer provides the Link Builder, which can be used to add two types of links, inbound links and outbound links, to an application. An inbound link is a reference that can be used to start or access a particular application on a server. The application may be, for example, with reference to
Inbound links are used, for example, when the originating web page or application is an external application such as Siebel or SalesForce.com. The user will use the Link Builder interface to build the link and then update the foreign application by pasting this link into the foreign application's user interface. The parameter values in an inbound link may be specified as attribute variables, for which values will be substituted by the Player UI when the link is presented to the Player UI. Attributes have the form name=value, where name is an attribute name and value is an attribute value. Attribute values are either literal values or placeholders. Placeholders have the syntax {!x }, where x specifies how to retrieve a value. An attribute variable appears in a link as, for example, un={!User_Username }, where {!User_Username} is a URL string replacement placeholder that will be replaced with actual values by the Player UI. For example, {!user_username} would be replaced with “John Smith” when the link is embedded and executed in another web page by a user named “John Smith”. The Player UI will retrieve an actual value for each attribute variable from the database and DefintionFactory, substitute the actual values into the link in place of the attribute variables, and pass the link with substituted values to the application. An outbound link is a reference to an object on a server, such as a web page on a web server. Outbound links may be included in button and link components of an application, and are displayed in the Player UI 114 of
Links can be used to define actions such as launching a Business Object Lookup dialog. The link may define properties related to launching the Business Object Lookup dialog and may also include JavaScript code that will populate application components with data from the Business Object Lookup dialog. Links can refer directly to business objects, in which case each instance of a business object can be identified, displayed, and invoked via a URL. The URL includes a generic server resource string and a unique ID for the business object. The URL may also include an instance identifier to identify of the business object. The business object will be invoked when the URL is selected, e.g. by a user clicking the associated link in the Player UI,
Table rows can also be populated by a link by including a link to a business object in the table definition. In this case, the Business Object Lookup dialog returns an array of values, and a function loops through all the lookup values and populates the table rows with the values.
The Application Designer supports Conditional Sections, which provide the ability to conditionally hide or show sections of the user interface. Each Conditional Section can include multiple elements. A user of the Application Player can insert or remove the components on a conditional section when filling out a form, for example. Conditional sections are hidden by default in the Form Player until an associated condition becomes true. For example, a travel request form could include a conditional Car Rental section that is not shown by default. Users will see the Car Rental section if they click on an associated button in the Form Player user interface.
Applications created using the Application Designer can invoke Web Services when executed in the Application Player. In a typical Web services scenario, an application sends a request to a service at a given URL using the Simple Object Access Protocol (SOAP) over HTTP. The service receives the request, processes it, and returns a response.
The Application Designer provides a Web Services Builder that can be used to select a Web Service for a button or Link component. The Web Service may provide a value for the component, or, vice versa, the component may provide a value for the Web Service. The Web Services Builder allows the user to select the web service to be invoked for component. Specifically, the user can select a web service vendor, an object, and a field. The user can also specify the invocation type, which can be query, update, insert, or delete. When the user selects a vendor, the Web Services Builder displays a list of objects based on the selected vendor. The user then selects an object, and the Web Services Builder displays a table of fields. The user selects a field and an operation to perform on the field. For example, the vendor Siebel may have an object named Opportunity, which has a number of fields, each of which corresponds to a sales opportunity. The Web Services Builder is described in more detail in application Ser. No. ______, filed one the same date as the present application and incorporated herein by reference.
b is an illustrative drawing of an application displayed in an Application Player user interface according to one embodiment of the invention. An Application Player user interface, e.g. the Player UI 114 of
f is an illustrative drawing of a Formula Builder user interface according to one embodiment of the invention. The Formula Builder 751 allows a user to define component values in terms of a formula 752. The formula 752 is an expression that can include the values of other components. The formula 752 is $cell.Qty*$cell.UnitPrice, which sets the value of the component associated with the formula to the product of a Qty and an ItemPrice, which are values in of a ProductDetails component. A user can enter the formula in a Formula Area 753. A data element list 754 shows a list of data elements. Each data element corresponds to a data-holding component of the application. When a user selects a data element from the list 754, e.g. by using a mouse, the name of the selected data element will be inserted into the formula. A formula can be based on the value of any component, including components that are in tables.
In one embodiment, an application also includes the ability to route data, e.g., by sending a copy of the application and associated data to another user. Routing may be performed, by example, by sending a link to the application in an email message. A routing is a specification of how an application is to be routed, e.g. via email to a particular email address. The radiology order request application 721 has been routed to a recipient user via email. The recipient user can approve the routing by selecting the Approve Routing button 722, or reject the routing by selecting the Reject Routing button 723.
g is an illustrative drawing of an Application List user interface according to one embodiment of the invention. The Application List user interface 780 lists applications, templates, and lookups that have previously been created using the Application Designer. A user can select an application displayed on the Application List 780 for modification in the Application Designer or execution in the Application Player.
Each application has a name and a version number. The name is a string, such as “Radiology Order Request”, that identifies the application, and the version number is a number that is incremented when an application is modified in the Application Designer. Applications can be saved as templates. An application can be in one of three modes: design mode, test mode, or production mode.
h is an illustrative drawing of an Inbound Link Builder user interface according to one embodiment of the invention. A user can start the Inbound Link Builder 755 from the Designer UI, e.g., by selecting a Create Inbound Link option from an Application menu (not shown). A user can use the Inbound Link Builder 755 to create an inbound link 756, e.g. a URL, by specifying a link type 757 and an application 758. An inbound link 756 is a web link, e.g., a URL, which can be exported to an external document, e.g. a web page, or an external application. Subsequently, selecting the inbound link from a web application can create a new application and open a Player UI for the new application, or can open an application list showing applications of a specified type.
In particular,
i is an illustrative drawing of an Outbound Link Builder user interface according to one embodiment of the invention. An outbound link, e.g. a URL, may be associated with a Button or a Link component of the application. An outbound link can open a web page specified by a static URL, or can initiate execution of another application. A user can use the Outbound Link Builder 765 to create an outbound link, e.g. a URL. A user can start the Outbound Link Builder 765 from the Designer UI, e.g., by clicking on a Link Builder button (not shown) that is present on the Control Properties panel 710 of the Designer UI 701 of
The Designer client 803 includes client components 807, and the Player Client 833 includes client components 837. The client components include JavaScript Definition object that implement a hierarchy of forms, areas, components, tables, properties, behaviors, methods, requests, responses, and parameters.
The Designer UI 805 and Player UI 835 are presented to a user as web pages. The web pages are provided by the server 850 to the web browsers 802 and 832 via the network 809 when a user enters a corresponding URL into the web browser. On the server, these web pages are App Designer JSP 852 and App Player JSP 860, for the designer and player, respectively. The web browser presents clients 803 and 833 to the user by displaying web pages generated by the App Designer JSP 852 and App Player JSP 860, respectively. These generated web pages include JavaScript code that uses JavaScript Client Components 807 and 837 to implement the Designer and Player user interfaces.
The App Designer JSP 852 is a page controller JSP that implements several action commands, including getDefinition, saveDefinition, saveDefinitionAsTemplate, createNewVersion, and lockdefinition, as described in the table below. These operations are invoked in response to corresponding user requests from the Designer UI 805 and Player UI 835.
The application server 850 may be JBoss™ from JBoss Inc. of Atlanta, Ga., or the like, and may include a container framework, e.g. the Spring Application Framework from Interface21 of London, United Kingdom, or the like, and provides services for executing the App Designer JSP 852 and the App Player JSP 860. These services may include a web server, HTTP network communication, fault tolerance, load balancing, application management, transaction management, dependency injection, and internationalization. The database 870 may be a relational database, e.g. Oracle™ or the like, and runs on a database server computer (not shown).
The application server 850 may be run by a service provider to provide the App Designer and App Player as hosted applications.
The application server 850 also includes a DefinitionFactory 854 a FormFactory 862 and a BusinessFactory 858. The DefinitionFactory 854 is a Java object that uses an object-relational mapping tool to create ProcessDefinition objects that correspond to rows in a process_definition database table. A ProcessDefiniton object contains an application definition in the form of an XML document. The DefinitionFactory 854 can generate a new empty application definition, or can load an existing application definition from the database 870, in which case the application is retrieved from the database 870 using an application identifier as a key. The application definition is used to render user interface portions of the App Designer JSP 852 and FormPlayer JSP 860. The ProcessService 856 provides an object-relational mapping for saving and loading the application definition and application data o and from the database 535.
The FormFactory 862 uses an XML application definition to render an HTML representation of the application, which may include application data retrieved from the database 870 if application data has previously been saved. The HTML representation is sent to a browser 832 running a Player Client 833 by the FormPlayer JSP 860. The FormPlayer JSP 860 uses a FormProcessor 864 to process incoming requests, e.g. HTTP messages, received from the Player Client 833 by extracting applicaton data, e.g. in the form of HTTP parameters, from the request and passing the application data to a BusinessFactory 858 for storage in the database 870. The ProcessService 856 uses an object-relational mapping tool, e.g. Hibernate from JBoss Inc., to convert the application definition from the server programming language, e.g. Java, to and from a relational table format such as that shown in
With reference to
With reference to
A user 118 of the Player UI 114 may invoke a command to load a previously-saved application, including application data, such as data concerting a particular person or transaction, data from the database 110 into the Player UI 114. After the Application Data 120 has been loaded, the Player UI 114 can be used to modify the Application Data 120 and save the modifications by invoking the save command as described above with reference to
a is a flowchart illustrating a method of loading an application according to one embodiment of the invention. This method loads a specified application definition and a specified instance of application data, if such an instance exists, into the Application Player. This method is executed on an application server by the App Player JSP page. The method produces a web page that includes HTML and JavaScript elements. The web page can be displayed in a web browser to provide the Application Player UI. The method of
The GetValues and RenderHTML subroutines both traverse the XML application description. These subroutines process an XML application definition data structure.
To load application data from the Database 110 of
Block 1030 uses the unique component name to look up dataset table and column names in the XML application definition. The dataset table and column names identify the database column in which the data value for the component is stored. At block 1032, the component's data value is retrieved from the database by requesting the value of the database column from the process_master table. At block 1034, the component's data value is stored in the BusinessObjectValue as a name-value pair, with the unique component name as the name portion of the pair, and the component's data value as the value portion of the pair. Finally, block 1036 checks if there are more components in the XML document to process. If so, the loop repeats for the next component.
The RenderHTML subroutine illustrated in
With reference to
a is an illustrative drawing of an application 1201 including a mode 1202 and a version number 1202 according to one embodiment of the invention. The application 1201 also includes an application definition 1203 and a set of application values 1204. These values may be included in a data structure that represents the application, or may be referred to by reference from such a data structure. Once an application has been defined, it can be used as part of a complex process, e.g. a procurement process that involves multiple steps. An application can also be routed to one or more users, e.g. via email, and the users must access the application in sequence. In both cases, users run the application in the Player UI and provide input data. Since an application's definition may be loaded multiple times in these processes or routings, it is important that application definitions not be modified, e.g. by the Designer UI, while such processes or routings are in progress. To prevent applications from being modified while processes or routings are in progress, the application mode 1202 is associated with each application, and the actions that a user may perform on an application are restricted based on the mode. The mode has one of the following values: Test, Active, or Inactive.
Furthermore, when an application is modified by the Designer UI, it is possible that the modification will remove or change components of the application. Any processes or routings that use the application and are in progress at the time of modification will become invalid if the application is saved with modifications to a component used by those in-progress processes or routings. To allow users to continue to modify applications in the Designer UI while processes or routings are in progress, the version number 1203 is associated with each application, and the version number is incremented every time the application is placed in active mode as described below.
b is an illustrative drawing of application mode transitions according to one embedment of the invention.
The effects of each action will now be described. With reference to the Application List of
The allowed actions for an application for display in the Actions column 782 can be determined from the application's current mode as illustrated by the following pseudocode.
When an action is selected, the mode and version number are incremented as shown by the following pseudocode:
Components can never be removed from an application, so backward compatibility is assured. Processes or routings that are executing with a version will always have access to all components of that version. There is no need to merge different versions together or lock an application definition to prevent modifications. An application definition can always be modified by creating a copy with a new version number. When a new version is created, all subsequent processes and routings will use the new version. Components can be hidden in the user interface by setting their hidden property to true, so that users will not see or interact with the components in future versions, but the components will be available for existing processes or routings that use those components. Multiple versions of an application can be active at any given time.
With reference to
The process_master table 1401 is related to the process_detail table 1420 by a process_master_id value, which is stored in the fk_process_master_id field 1403 of the process_master table 1401, and in the fk_process_master_id field of the process_detail table 1420. The process_master table 1401 and the process_extension table 1430 are similarly related by a process_master_id value. This process_master_id relation allows additional rows to be used for storing information about an application, e.g. additional application data values, which may be stored in the process_extension table. In particular, if an application contains more components than can be represented in the process_master table (more than 3 components of the same type, in the example of
The process_attachment table 1410 is related to the process_master table 1401 by a process_master_id value, which allows attachments to be stored in the process_attachment table 1410 and retrieved by selecting a row from the process_attachment table that has the same process_master_id value as a corresponding row of the process mater table 1401.
The process_detail table 1420 has a TYPE_ID column 1421 and a PARENT_ID column 1422 for representing complex, hierarchical data relationships. A unique TYPE_ID 1421 is associated with each table area. All data rows of a table area will have the same value for the TYPE_ID 1421. Different tables will have different values for the TYPE_ID 1421. The TYPE_ID 1421 is used for applications whose data relationships are of type Master-(n) Detail, i.e. a single set of components with an associated table of rows, such as most web applications of medium complexity. Each data row in the process_detail table also Parent_ID 1422, which is associated with each data row in a table area. The Parent_ID 1422 is used for applications whose data relationships are of type Master-(n) Detail-(n) Detail, i.e., a single set of components with an associated table of rows, which in turn has another table of rows. Examples of the latter type of application include Bill of Materials applications used in manufacturing and Enterprise Resource Planning systems to represent hierarchical product configurations.
Specific examples of how an application design and deployment system is used will now be described. Each example includes a set of steps to be performed by the user and the system. The examples include creating an application, saving an application, saving an application as a template, editing an application in test mode, previewing an application in design mode, initiating test routings in test mode, editing saved routings in test mode, saving a new application version in test mode, deploying an application to production mode, deactivating an application from production mode, copying an application from production mode to test mode, and deleting an application in test mode. A routing is, for example, a message that transmits an application between users, such as an email message that contains a URL link to an application.
Creating a new application involves the following steps:
When these steps are complete, the new application screen has been saved in test mode and is available for initiating test routings and deployment to production. Creating a new application from a template involves the same steps, except step 1 includes launching the Application Designer UI with a selected template UI displayed in the workspace.
Editing an application in test mode involves the following steps:
When these steps are complete, the application definition has been updated and saved in test mode. The application definition is available for initiating test routings and for deployment to production mode.
Initiating test routings in test mode involves the following steps:
Editing saved routings in test mode involves the same steps listed above for initiating test routings in test mode, except that in step 2, the system also populates the existing application data in the user interface.
Deploying an application to production mode involves the following steps:
When these steps are complete, a new application definition has been created with a new version number and saved in production mode. The effective date of the application is set to the current date or whatever date the user specifies in the deployment dialog.
An application may be deactivated, for example, when an application administrator wants to un-deploy a production application to make modifications to the application. Deactivating from production mode involves the following steps:
When these steps are complete, the selected production application is inactivated.
Copying an application from production mode involves the following steps:
When these steps are complete, a new application definition has been created with a new version number and saved in test mode.
Copying from an application in test mode involves the following steps:
When these steps are complete, a new application definition has been created with a new version number and saved in test mode.
Deleting an application in test mode is accomplished by setting a delete indicator for the application's definition in the database and hiding the definition from the UI. All test routings based on the definition will still work with the existing definition.
Initiating routings in production is accomplished by initializing the Player UI with the latest application version in production that is marked as active. Previous versions of the application are only used for in-progress routings.
The Application Designer and Player meet the need for an easy-to-use tool for developing Web-based data processing applications that allow for data input, validation, processing, and linkage with Web services, and enable the creation of applications by the non-technical user community. Since the Designer and Player are Web-based, they can be used by any user who is familiar with a web browser. The Designer's user interface allows a user to create Web-based applications that include forms for accepting data input. A web application's user interface can be defined in terms of a user interface and data values. Linkage between the data values, a database, and scripts are determined by the Designer based on minimal input from a user.
The Designer's action builder adds processing in scripting language, the link builder adds input and output of data from and to external sources, and the Web Services builder adds interaction with Web Services. The combination of these features provides a comprehensive, easy-to-use, application development tool.
The above description is exemplary only and it will be apparent to those of ordinary skill in the art that numerous modifications and variations are possible. For example, various exemplary methods and systems described herein may be used alone or in combination with various other computer and computer peripheral systems and methods. Additionally, particular examples have been discussed and how these examples are thought to address certain disadvantages in related art. This discussion is not meant, however, to restrict the various examples to methods and/or systems that actually address or solve the disadvantages.