1 of documents 208. In integrated development system 202, the document 208 comprises at least one structured data object 212 that is composed from tiles 214. Graphical user interface 210 displays tiles 214 in a first area 216 of the graphical user interface 210. Each tile, such as tile 218, corresponds to a set of data nodes. As depicted, tile 218 corresponds to data node 220 of structured data object 212. Tiles 214 are composable into structured data objects, such as structured data object 212, according to a domain-specific language of the integrated development system 202.

In one illustrative example, revision manager 204 identifies, in sequence, one or more revisions 222 to the structured data object 212. Revisions 222 change a state of a data node of the structured data object, such as data node 220. In one illustrative example, revisions 222 to the structured data object 212 can be, but are not limited to, changing one or more properties 224 of data node 220, changing one or more values 226 of data node 220, appending an additional one or more of tiles 214 to the structured data object 212, and deleting a tile, such as tile 218, from structured data object 212.

In this illustrative example, revision manager 204 can identify revisions 222 in a number of different ways. For example, revision manager 204 can receive user input that revises one or more properties or values of data nodes of the structured data object, appends an additional one of tiles 214 to the structured data object, or deletes a tile from the structured data object. User input can be generated by a human machine interface that comprises an input system and a display system 207, enabling a user, such as user 124 of FIG. 1, to interact with integrated development system 202.

In one illustrative example of managing document 208, revision manager 204 displays the revisions 222 in a draft history 228 for the document 208. In one illustrative example, draft history 228 can be embodied as a drop-down list, modal, or other control element containing a list of data nodes that has been changed. Revision manager 204 displays the draft history 228 in response to receiving a selection of a control element 230 displayed in the graphical user interface.

In one illustrative example, the draft history 228 comprises: a list 232 of data nodes that has been changed; and a separate undo control 234 associated with each data node in the list 232. Each of the data nodes in the list 232 and the separate undo controls 234 are themselves graphic controls through which a user can interact with revision manager 204.

In one illustrative example, revision manager 204 receiving a selection of a data node from the list 232. In response to receiving the selection, revision manager 204 focuses a second area 236 of the graphical user interface 210 on the data node. In one illustrative example, the focusing can include highlighting the revision, including changes to properties 224 and values 226, in a third area 238 of the graphical user interface 210.

In one illustrative example, revision manager 204 can receive a selection of an undo control 234 associated with a data node in a list 232. In response to the selection, revision manager 204 reverts the associated data node to a prior state 240. Interacting with undo control 234 in draft history 228 of graphical user interface 210 enables a user to individual revert a revision of a data node to a prior state, irrespective of the sequence in which the revisions were received and without reverting other data nodes of the structured data object 212 to their prior state.

In one illustrative example, one or more technical solutions are present that overcome a technical problem with of quickly and easily generating new templates and applications. As a result, one or more technical solutions may provide a technical effect in which a new templates and applications are generated more easily and quickly while requiring less knowledge or training from an operator.

Computer system 206 can be configured to perform at least one of the steps, operations, or actions described in the different illustrative examples using software, hardware, firmware or a combination thereof. As a result, computer system 206 operates as a special purpose computer system in which revision manager 204 in computer system 206 enables a user to create new reports, applications, and templates more easily and quickly while requiring less knowledge or training. In particular, revision manager 204 transforms computer system 206 into a special purpose computer system as compared to currently available general computer systems that do not have revision manager 204.

In the illustrative example, the use of revision manager 204 in computer system 206 integrates processes into a practical application for creating a template in an integrated development environment that increases the performance of computer system 206 In other words, revision manager 204 in computer system 206 is directed to a practical application of processes integrated into revision manager 204 in computer system in 206 that manages revisions in a document within an integrated development environment. In this illustrative example, revision manager 204 in computer system 206 displays the document in a graphical user interface, the document comprising a structured data object composed from a set of tiles, wherein each tile corresponds to one or more data nodes, wherein the tiles are composable according to a domain-specific language of an integrated development environment; identifies, in sequence, one or more revisions to the structured data object; independently manages revisions to each data node of the set of tiles composing the structured data object wherein each revision can be independently reverted to a prior state irrespective of the sequence and revisions to other data nodes of the set of tiles; and reverts a revision of the data node to a prior state irrespective of the sequence and without reverting the other data nodes of the structured data object to their prior state. In this manner, revision manager 204 in computer system 206 results in an improved integrated development system that provides a practical application of managing revisions in a document such that the functioning of computer system 206 is improved.

The illustration of revision manager 204 in FIG. 2 is not meant to imply physical or architectural limitations to the manner in which an illustrative embodiment can be implemented. Other components in addition to or in place of the ones illustrated may be used. Some components may be unnecessary. Also, the blocks are presented to illustrate some functional components. One or more of these blocks may be combined, divided, or combined and divided into different blocks when implemented in an illustrative embodiment.

FIG. 3 is a block diagram illustrating an application development system depicted in accordance with an illustrative embodiment. Application development system 300 may be used to manipulate composable data nodes to build at least one of business rules, mini-apps, and apps. application development system 300 is one example of integrated development system 202 of FIG. 2.

User interface engine 302 is computer code, underlying data and structured data objects which provide underlying functionality and implementation capability for application designers using application development system 300. Primarily, user interface engine 302 operates client-side, meaning that user interface engine 302 operates on a specific client user's computer, such as one or more of client computer 112, client computer 114, and client computer 116 of FIG. 1. In one illustrative example, user interface engine 302 could be a web browser or an extension to a web browser.

Underlying the user interface, user interface engine 302 may include one or more modules. As depicted, user interface engine 302 includes tile renderer module 304, data and metadata binding module 306, and business rule and workflow module 308. Each module may be considered a collection of software or computer code which implements the functionality of the module.

Tile renderer module 304 is computer code which computer 310 may use to render tiles on tangible user display device 312. Tile renderer module 304 may receive input from the user, from data and metadata binding module 306, and from business rule and workflow module 308 to change and manipulate both the functionality of computer 310, which is used to execute tile renderer module 304, as well as tangible user display device 312, which is used to display rendered tiles.

Data and metadata binding module 306 is computer code which computer 310 may use to bind data and structured data objects to the user interface, possibly a browser, so that user interface engine 302 may keep track of all of the data and structured data objects used in executing business rules and workflows, as well as rendering tiles. Additional details regarding the functionality of data and metadata binding module 306 is described below with respect to how data and structured data objects are used in user interface engine 302.

Business rule and workflow module 308 is computer code which computer 310 may use to create, join, merge, or otherwise manipulate composable data nodes in order to create mini-apps, collections, and bundles. Business rule and workflow module 308 is the underlying code which allows a user to create mini-apps, collections, and bundles without the user having to code any of the software being developed. Using data and structured data objects tracked by data and metadata binding module 306, the user can manipulate tiles rendered by tile renderer module 304. Business rule and workflow module 308 uses these composable data nodes, together with work flows and business rules to create the mini-apps, collections, or bundles in a user-perceived codeless development environment.

Node interpreter 314 is hardware or software which is used to interpret or execute business rules in a business system. Node interpreter 314 can be software residing in a web browser on computer 310. However, the illustrative embodiments are not necessarily limited to only client computers or web browsers.

Node interpreter 314 is a code interpreter designed for a domain-specific language entirely composed of structured data objects. In one illustrative example, node interpreter 314 takes the form of an abstract syntax tree (AST) interpreter with the exception that the abstract syntax tree (AST) structure is composed of well-defined data nodes constructs, joined together in a domain-specific language. Because the data node constructs are well-defined when they are constructed, node interpreter 314 executes the composition of structured data objects without compilation. Data node constructs are composed into well-defined structured data objects according to selected block types and properties, replacing the tokenization and parsing that would otherwise occur during compilation.

In some illustrative embodiments, user interface engine 302 may take advantage of some server-side services operating on one or more server computers, such as server computer 316. “Server-side” means that computer 310 communicates with server computer 316, possibly over a network such as the Internet. Server-side resources are provided to support user interface engine 302. While not always necessary for implementation of user interface engine 302, server-side resources can enhance the functionality of user interface engine 302.

For example, the server-side resources may include user interface engine orchestrator 318. In some exemplary illustrative embodiments, user interface engine orchestrator 318 may be considered part of user interface engine 302 such that user interface engine 302 operates partially both on computer 310, but also on one or more server computers, such as server computer 316.

User interface engine orchestrator 318 may serve as a proxy to speed up processing of user interface engine 302. User interface engine orchestrator 318 may retrieve structured data objects and then identify whether data queries are for customer data, business rules, or any other structured data objects. User interface engine orchestrator 318 may then request such data, objects, or code, from the data center operating server-side. User interface engine orchestrator 318 may cache retrieved data, structured data objects, code, workflows, or objects to be sent back to user interface engine 302.

Server-side services may include other components other than user interface engine orchestrator 318. For example, server-side resources could include one or more metadata and DNA engines 320, which can be used to manage or provide structured data objects for use in user interface engine 302. Server-side resources may also include one or more persistence engines 322, which can be used to save work done using user interface engine 302. Server-side resources may also include business rule engine 324, which may be used to create or store business rules that are used by user interface engine 302 in the user-perceived codeless building of mini-apps, collections, and bundles.

Server-side resources may also include workflow engine 326, which may be used to create or store workflows that are used by user interface engine 302 in the user-perceived codeless building of mini-apps, collections, and bundles.

Server-side resources may also include user interface test engine 328, which may be used to test both the functionality of user interface engine 302, possibly as well as the mini-apps, collections, and bundles created using user interface engine 302.

FIG. 4 is an illustration of a block diagram of an example of an operation of a user interface engine shown in FIG. 3, in accordance with an illustrative embodiment. The example shown in FIG. 4 does not necessarily limit operation of user interface engine 302 as shown in FIG. 3. Nevertheless, FIG. 4 may be read in conjunction with FIG. 3.

In an illustrative embodiment, tile renderer module 304 in FIG. 3 may be used to generate graphical user interface 400. Graphical user interface 400 may take the form of tiles 402 shown in web browser 404. Each of tiles 402 may represent a building block. Alternatively, a tile may represent a mini-app, a collection, or even a bundle. Users may interact with graphical user interface 400, triggering, for example, a “view actions” command 406.

These actions are sent to dispatcher 408, which may be part of user interface engine 302, shown in FIG. 3. Dispatcher 408 may send the actions to the business rule and workflow module via subscriptions registered with dispatcher 408. Dispatcher 408 may also send server actions 410 sent by data center 412 to business rule and workflow module 308 in FIG. 3 for use in combination with the actions started by the user.

Business rule and workflow module 308 may run queries and apply business rules and other logic. Business rule and workflow module 308 may provide navigation 414, data binding 416, and execution by business rules and workflows executor 418.

Data and metadata binding module 306 in FIG. 3 may apply changes to user interface state held in memory. User interface state may be held in a tree structure containing data 422, data nodes 424, and tile state 426. In turn, tile renderer module 304 in FIG. 3 may render graphical user interface 400. Tile renderer module 304 may listen to state changes in the tree structure and efficiently update only data 422 and data nodes 424 that need re-rendering.

With reference next to FIG. 5, an illustration of a block diagram of a structured data object is depicted in accordance with an illustrative embodiment. Structured data object 500 is an example of a composition of well-defined data nodes that can be linked together according to a domain-specific language to create mini-apps, collections, or bundles in a user-perceived codeless development environment, such as application development system 300 of FIG. 3.

Structured data object 500 includes data nodes 510, 512, and 514. Data nodes 510, 512, and 514 are well-defined structured data objects that can be manipulated within data and metadata binding module 306 of FIG. 3 to create desired business rules. Tile renderer module 304 of user interface engine 302 may visually present data nodes 510, 512, and 514, enabling the user to build different business rules, mini-apps and apps in application development system 300 of FIG. 3. Each of data nodes 510, 512, and 514 correlates to one or more functions, which in turn can be interpreted by node interpreter 314 of FIG. 3 for implementing the corresponding business rule. The different permutations of the compositions of these functions, as well as differentiated input, enable the execution of the different business rule behaviors at runtime.

The functions of data nodes 510, 512, and 514 operate inside of a context defined at the beginning of the business rule execution step, which is the target object for all symbols defined in the course of the business rule execution, as well as for all input to and output from the business rule itself. In this manner, data nodes 510, 512, and 514 act as a configuration object to the code being executed, defining an execution context (or scope being executed against) to other joined data nodes.

For example, structured data object 500 further includes data node 516. Data node 516 provides additional context for execution of related data node 512. Specifically, data node 516 may indicate that data node 512, as well as child data nodes thereof, should be interpreted within the context of data node 516.

Structured data object 500 further includes data node 518. Data node 522 provides additional context for execution of both related data node 512 and data node 516. For example, data node 522 may indicate that information required for execution of data node 512 should be requested and received from one or more web services. Data node 522 requests and returns the same context updated with the information received through the web services.

Structured data object 500 further includes business rule node 520. Business rule node 520 provides additional context for execution of related data node 514. Specifically, business rule node 520 may indicate a consuming service for receipt of business rule output provided by related data node 514. Business rule node 520 requests and returns information to a consuming service, such as a web page.

With reference next to FIG. 6, a graphical user interface for composing structured data objects according to a domain-specific language is depicted according to an illustrative example. Graphical user interface 600 is an example of graphical user interface 210 of FIG. 2.

As depicted, graphical user interface 600 includes a first area 602. First area 602 displays tiles 604. Tiles 604 are examples set of tiles 214, shown in block form in FIG. 2.

As depicted, graphical user interface 600 includes a second area 606. Second area 606 is an example of second area 236 of FIG. 2. Second area 606 displays a plurality of data nodes that have been linked together to form a structured data object 608 according to a domain-specific language. Dragging tiles from a first area 602 to second area 606 appends the corresponding set of data nodes into a structured data object 608 according to the context defined by parent nodes.

As depicted, graphical user interface 600 includes third area 610. Third area 610 is an example of third area 238 of FIG. 2. Third area 610 displays properties and values for the various data nodes of structured data object 608.

With reference next to FIG. 7, a graphical user interface 600 is illustrated having a drop-down menu according to an illustrative example. In an illustrative example, graphical user interface 600 displays drop-down menu 702 in response to receiving user input that selects control element 703. Drop-down menu 702 is an example of draft history 228 of FIG. 2.

In an illustrative example, drop-down menu 702 displays a list of data nodes 704 effected by changes to structured data object 608. Additionally, drop-down menu 702 displays an undo control 706 for each of data nodes 704 that has been changed. Interacting with the undo control 706 elements of drop-down menu 702 allows the user to individually revert changes in the associated structured data object to a prior saved state.

With reference next to FIG. 8, an expanded data node within a drop-down menu is depicted according to an illustrative example. Drop-down menu 702 is drop-down menu 702 of FIG. 7.

In an illustrative example, each data node 704 displayed within the drop-down menu 702 includes a toggle control 802. User interaction with the toggle control 802 expands the data node to display the properties 804 of the data node that have been changed from their prior state. As illustrated, each property displayed displays is associated with an undo control 806 that allows the user to individually revert a property of the data node to a prior saved state without affecting changes made to the other properties of the node.

With reference next to FIG. 9, graphical user interface 700 having multiple selected data nodes in a drop-down menu 702 is illustrated according to an illustrative example.

In this illustrative example, each data node 704 is associated with a selection control 902, allowing the user to select one or more data nodes from the drop-down menu 702. By selecting multiple nodes, graphical user interface 700 enables a user to collectively revert multiple data nodes to their prior state in a single user interaction with undo control 904.

With reference next to FIG. 10, a graphical user interface is shown focused on a node of a structured data object according to an illustrative embodiment. Graphical user interface 700 focuses second area 606 in response to a selection of one of data nodes 704 from the drop-down menu 702.

As illustrated, graphical user interface 600 has focused structured data object 608 on data node 1002. When a user clicks on one of data nodes 704 from the drop-down menu 702, the graphical user interface 600 scrolls second area 606 so that the data node selected from drop-down menu 702 is more prominently displayed in second area 606. Additionally, data node 1002 can be highlighted or otherwise emphasized in second area 606 to draw a user's attention to the selected data node relative to the other nodes of structured data object.

Additionally, graphical user interface 600 scrolls third area 610 so that a changed property 1004 of the selected data node 1002 is more prominently displayed in third area 610. Additionally, the changed property 1004 can be highlighted or otherwise emphasized in third area 610 to draw a user's attention to the changed property of the selected data node.

With reference next to FIG. 11, graphical user interface 600 is illustrated showing a deleted node of a structured data object according to an illustrative example.

In this illustrative embodiment, when a deleted data node is selected from drop-down menu 702, graphical user interface 600 displays the deleted node 1102 in a read-only mode within second area XYZ. Additionally, graphical user interface 600 scrolls second area XYZ and third area 610 to more prominently display the deleted node 1102 and properties 1104 of the deleted node 1102. Additionally, the deleted node 1102 and its properties 1104 can be highlighted or otherwise emphasized relative to the display of other nodes and properties.

Turning next to FIG. 12, a flowchart of a process for managing revisions in a document in an integrated development environment is depicted in accordance with an illustrative embodiment. The process in FIG. 9 can be implemented in hardware, software, or both. When implemented in software, the process can take the form of program code that is run by one of more processor units located in one or more hardware devices in one or more computer systems. For example, the process can be implemented in revision manager 204 in computer system 206 of FIG. 2.

The process begins by displaying the document in a graphical user interface (step 1210). The document comprising a structured data object composed from a set of tiles, wherein each tile corresponds to one or more data nodes. The tiles are composable according to a domain-specific language of an integrated development environment.

The process identifies, in sequence, one or more revisions to the structured data object (step 1220). The process independently manages revisions to each data node of the set of tiles composing the structured data object (step 1230). Because each data node and its revisions are independently managed, each revision can be independently reverted to a prior state irrespective of the sequence and revisions to other data nodes of the set of tiles. In one illustrative example, each revision to the structured data object comprises changing a property of a data node for a tile, changing a value of a data node or a tile, appending an additional tile to the structured data object, or deleting a tile from the structured data object

The process reverts a revision of the data node to a prior state irrespective of the sequence and without reverting the other data nodes of the structured data object to their prior state (step 1240). The process terminates thereafter.

With reference next to FIG. 13, a process for process for managing revisions to a document by displaying a draft history is depicted according to an illustrative example. The process in FIG. 15 can be implemented as part of one illustrative example of the process of FIG. 10.

Continuing from step 1230 of FIG. 12, the process displays the revisions in a draft history for the document (step 1310). The draft history can be draft history 228 shown in block form in FIG. 2. In one illustrative example, step 1310 can include receiving a selection of a control element displayed in the graphical user interface (step 1320). The process displays the draft history in response to receiving the selection (step 1330).

The process receives a user interaction with the draft history (step 1340). The process proceeds to step 1240 of FIG. 12 thereafter.

In one illustrative example, the draft history can include a list of data nodes that has been changed. In this illustrative example, step 1340 can include receiving a selection of a data node from the list (step 1350). In response to receiving the selection, the process focuses a second area of the graphical user interface on the data node, and highlights the revision in a third area of the graphical user interface (step 1360).

In one illustrative example, the draft history can further include separate undo control associated with each data node in the list. In this illustrative example, the process can include receiving a selection of an undo control associated with a data node (step