State Management Persistence

Abstract

To provide a design time tool, a method and a storage device which create a code without using a high-level programming mechanism for exclusion control of a process.SOLUTION: A hierarchy of containers is received at a user interface of a design time tool. The hierarchy of containers includes a container nested inside of one or more other containers. Each of the containers includes a different part of a web client application. The design time tool associates state with each of the containers in the hierarchy of containers. Life cycles for each of the containers are received at the user interface. The design time tool creates instructions in the web client application that enable state for each of the containers to be created and destroyed according to the hierarchy based on the respective life cycles of each of the containers. The design time tool provides each of the containers access to its own state and state of containers that include it based on respective lifecycle events associated with each of the containers.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application relates to U.S. Patent Application No. 16 / 003023, filed June 7, 2018, entitled "State Management Persistence," U.S. Provisional Patent Application No. 62 / 564945 (Reference No. ORACP0208P-1 / ORA180300-US-PSP), filed September 28, 2017, entitled "State Management Persistence," and U.S. Provisional Patent Application No. 62 / 629523 (Reference No. ORACP0208P-2 / ORA180300-US-PSP- 2), and to U.S. Provisional Patent Application No. 62 / 564,946 (Reference No. ORACP0209-1 / ORA180301-US-PSP), filed September 28, 2017, entitled "Router Configuration," and U.S. Provisional Patent Application No. 62 / 629,526 (Reference No. ORACP0209P-2 / ORA180301-US-PSP-2), filed February 12, 2018, entitled "Router Configuration," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] background A process is a piece of code that is executed to achieve a function. In a parallel processing system, multiple processes can run simultaneously. Two or more of these processes can update a shared state (also called "shared state"). If two or more processes update the shared state at the same time or near the same time, a conflict can occur. For example, if two processes share a variable Y, and the first process updates the value of variable Y to 4 and the second process updates the value of variable Y to 5, the update of the first process will be wiped.

[0003] Traditionally, the problem of multiple parallel processes simultaneously updating a shared state has either not been addressed at all or has been addressed using advanced programming mechanisms such as locks, mutexes, or critical sections. For example, traditionally, the advanced programming mechanisms prevent simultaneous execution of instructions corresponding to a first process and a second process. Thus, execution of the first process and the second process are mutually exclusive. However, to write code that uses such advanced programming mechanisms, a developer must have advanced programming skills. Summary of the Invention [Means for solving the problem]

[0004] overview A design container hierarchy is received at a user interface of the timing tool. The container hierarchy contains containers nested inside one or more other containers. Each container contains a different portion of the web client application. The design-time tool associates a state with each container in the container hierarchy. The lifecycle of each container is received at the user interface. The design-time tool creates computer-executable instructions in the web client application that enable the creation and destruction of each container's state according to the hierarchy and based on each container's lifecycle. The design-time tool provides each container with access to its own state and the state of containers that contain it based on lifecycle events associated with each container.

[0005] One embodiment provides a non-transitory computer readable medium including instructions for performing a method for providing state management persistence. The method includes receiving, at a user interface of a design-time tool, a container hierarchy that includes containers nested within one or more other containers, each container including a different portion of a web client application, associating, with the design-time tool, a state with each container in the container hierarchy, receiving, at the user interface of the design-time tool, a lifecycle of each container, using the design-time tool to create computer-executable instructions in the web client application that enable the web client application to create and destroy a state for each container according to the hierarchy and based on the lifecycle of each container, and using the design-time tool to provide, for each container, access to its own state and the state of any containers that include it based on lifecycle events associated with each container.

[0006] A further understanding of the nature and advantages of specific embodiments disclosed herein may be realized by reference to the following description and accompanying drawings. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 2 illustrates a URL, according to various embodiments. [Figure 2] FIG. 2 is a block diagram illustrating a container hierarchy, according to one embodiment. [Figure 3] FIG. 1 illustrates a configuration of a container, according to various embodiments. [Figure 4] FIG. 1 illustrates a system according to various embodiments. [Figure 5A] FIG. 1 illustrates a chain of operations being performed in parallel, according to one embodiment. [Figure 5B] FIG. 1 illustrates an implementation of snapshots, according to one embodiment. [Figure 6] FIG. 10 illustrates a page for creating an action chain for a button that is part of a client application's UI, according to one embodiment. [Figure 7] FIG. 10 illustrates a screenshot of a settings panel page, according to one embodiment. [Figure 8] FIG. 1 illustrates a web page for associating lifecycle events with user interface components according to one embodiment. [Figure 9] FIG. 1 illustrates a web page for generating a verification code, according to one embodiment. [Figure 10] FIG. 10 illustrates a web page for selecting an action chain, according to one embodiment. [Figure 11] FIG. 10 illustrates a web page that a developer can use to map input parameters required for an operation chain that uses the page, according to one embodiment. [Figure 12] FIG. 1 illustrates a web page that a junior developer can use to associate a user interface (UI) component with a component event, according to one embodiment. [Figure 13] FIG. 1 illustrates a web page containing an event listing, according to one embodiment. [Figure 14] FIG. 10 illustrates a property inspector for specifying input parameters according to one embodiment. [Figure 15] FIG. 10 illustrates a property inspector with page selection buttons, according to one embodiment. [Figure 16] FIG. 1 illustrates a page selection dialog box showing a list of pages within a client application that a developer is creating, according to one embodiment. [Figure 17] FIG. 10 illustrates a property inspector for specifying the name of an action, according to one embodiment. [Figure 18] FIG. 10 illustrates a dialog box for mapping variables to parameters, according to one embodiment. [Figure 19] 1 is a flowchart illustrating a method for providing state management persistence according to one embodiment. [Figure 20]1 is a flowchart illustrating router configuration according to one embodiment. [Figure 21] FIG. 1 illustrates a system according to one embodiment. [Figure 22] FIG. 1 is a schematic block diagram illustrating a system and associated computing environment that can be used to implement the embodiments illustrated in the figures herein. [Figure 23] FIG. 1 is a schematic block diagram illustrating a computing device that can be used to implement embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] Detailed Description of the Embodiments A problem occurs when one computer-executable instruction reads state, such as a variable, while another computer-executable instruction modifies that state. Traditionally, this problem has not been addressed at all, or has been addressed using advanced programming mechanisms such as locks, mutexes, or critical sections. However, to write code that uses such advanced programming mechanisms, developers must have advanced programming skills. Various embodiments of state management persistence address these problems in a way that enables less-skilled developers to write code without using advanced programming mechanisms.

[0009] Various embodiments provide automated handling of creating, restoring, and destroying portions of application state. A persistence lifecycle can be used to mimic browser behavior, such as session persistence and history state.

[0010] Various embodiments provide at least two aspects of state management: containership and lifetime.

[0011] Containership (also called "scope") comes into play when a piece of state is active. For example, page-scoped state is contained in a page. According to one embodiment, page-scoped state is only available while the page is being viewed and becomes unavailable once the user navigates away from the page.

[0012] Persistence refers to the period of time a system maintains its state. Using the web as an example, state may be maintained for the entire web session (state exists until the user closes the browser tab), may be maintained between web sessions (state exists if the user closes the browser tab and comes back), or may be used to mimic browser history (state exists if the user hits the "back" button, but no state exists if the user navigates directly to a part of the user interface).

[0013] State can be managed through a combination of containership and persistence. For example, when a user interacts with the UI to display a page, all state contained in that page is initialized and made available. With persistence, state is set to default values ​​and saved upon initialization.

[0014] Traditionally, a URL (uniform resource locator) alone was used to specify the path to display a page. Thus, web applications, modules, pages, and URLs or resources within a browser and other pages are independent of each other, regardless of their presence within the application's structure. Various embodiments provide a method for locating applications, modules, and pages based on portions of the URL (also referred to herein as "router settings"). Provides control over the state of

[0015] Various embodiments provide a highly modular way to compose applications, where each sub-path of the URL represents a module with its own initiation / destruction lifecycle.

[0016] Containership (also referred to herein as "scope") comes into play when a piece of state is active. For example, page-scoped state is contained in a page. According to one embodiment, page-scoped state is only available while the page is being viewed and becomes unavailable once the user navigates away from the page.

[0017] A container in an exemplary system can be a page (a page of the UI that the user is viewing), a flow (multiple pages), an application (multiple flows), etc. Each container described herein has its own set of states that are managed independently.

[0018] For illustrative purposes, the following URL is used as an example: https: / / mycompany.com / sales / accounts / contact This URL should contain the "mycompany", "sales", "accounts", and "contact" parts. It can be broken down into parts: "mycompany.com" represents the entire application, the "sales" and "accounts" parts each represent a nested flow, and the final "contact " represents the page that loads in the web browser.

[0019] This URL first creates the application state, then the "sales" flow, You can then create the states for the "accounts" flow and finally the "contact" page.

[0020] As an example, suppose a user navigates to the following URL: https: / / mycompany.com / sales / opportunity / detail In this case, the user can access the same application, i.e. "mycompany.com", and It is located in the "sales" flow, away from the "accounts" flow and the "contact" page. Thus, according to one embodiment, the system Maintain the state of the flow, as well as the state of the "accounts" flow and the "contact" page. Destroy it, then initialize the state of the "opportunity" flow and the "detail" page.

[0021] FIG. 1 is a diagram illustrating a URL in accordance with various embodiments. Each URL 110, 120, and 130 includes portions 101-103, 122, 123, and 133 separated by backslashes. The first backslash 100 of each URL represents an application. The last portions 103, 123, and 133 of URLs 110, 120, and 130 represent web pages within the corresponding application. The portions 101, 120, and 122 between the first backslash 100 of each URL 110, 120, and 130 represent modules.

[0022] According to one embodiment, each application, module, and page resides in its own container, and parts of the URL are used to determine navigation within the application, module, and page, and to determine when to create and destroy variables, e.g., state, for each container.

[0023] If you enter URL 110, 120, or 130 into your browser, the browser will display the corresponding page. For example, if you enter URL 110, the "ExpenseReports" page will be displayed. If you enter URL 120, the "Employee" page will be displayed.

[0024] FIG. 2 is a block diagram illustrating a container hierarchy according to one embodiment. Application container 210 includes SaaS cloud module container 220, module 250, and pages 211 and 212. SaaS cloud module container 220 includes a human resources module container 230 and a finance module container 240. The human resources module container includes an employee pages container 231. The finance module container 240 includes an expense report pages container 241 and a receipt pages container 242. Module container 250 includes page containers 251 and 252.

[0025] Containers are organized into a container hierarchy 200. Containers within hierarchy 200 can be nested. The hierarchical path (also referred to as a "hierarchical path") corresponding to each container is defined by the containers that contain that container and the order of the contained containers. For example, hierarchical path 261 for receipt page container 242 is defined by receipt page container 242 within financial module container 240 within SaaS cloud module container 220 within application container 210. FIG. 2 illustrates other hierarchical paths 262-267 along various nested containers. According to one embodiment, each container can have an associated hierarchical path.

[0026] FIG. 3 illustrates a configuration of a container, according to various embodiments. The module container 310 includes a scope 320 and JavaScript code 330. The scope 320 includes variables 321 used by the module container 310, action chains 322 that are executed as part of the module in the container 310, and a lifecycle 323 for the module container 310.

[0027] The page container 340 includes HTML (HyperText Markup Language) 341, a scope 350, and JavaScript 360. Scope 350 includes variables 351 used by page container 340, action chains 352 that are executed as part of the page of container 340, and lifecycle 353 of page container 340.

[0028] An application container can contain one or more module containers and / or one or more page containers. As shown in Figure 2, containers can be nested within other containers to any depth to form a container hierarchy with various hierarchical paths.

[0029] Each container 310, 340 has an associated lifecycle 323, 353. The lifecycle includes phases, such as a "beforeEnter" page, an "enter" page, an "interactable" page, a "canExit" page, which means the page can be exited, and so on. ", and a "beforeExit" phase that occurs before exiting the page. The phases are mutually exclusive; in other words, only one phase can be running at a time in the container's lifecycle. Furthermore, the phases run sequentially. More specifically, the "beforeEnter" phase is followed by the "Enter" phase, which is followed by the "interactable" phase, and finally the "beforeExit" phase.

[0030] A lifecycle phase is an event that can be used to start an action chain.

[0031] FIG. 4 illustrates a system 400 in accordance with various embodiments. The system 400 includes a tool 410, a hardware memory 420, a database 430, a server application 450, a server application 460, a client application 440, and a network 470 for communication between the elements 410, 420, 430, 450, 460 and the element 440. The design-time tool 410 is a user interface. The client application 440 provides a user interface 411. The client application 440 includes code 441 and a user interface 442.

[0032] According to one embodiment, the client application 440 is executed on or by the tool 410. The tool 410 and the client application 440 can be executed on the same computer or on separate computers that communicate with each other.

[0033] The design-time tool 410 includes a user interface 411, e.g., a web page, for creating a client application 440. The tool 440 can provide visual application building functionality that a developer or development team uses via the cloud to create the client application 440. The Visual Builder Cloud Service (VBCS) has been modified to provide various embodiments of the visual application building functionality described herein. The code 441 includes computer-executable instructions created by the tool 440 based on inputs made by the developer or development team into the user interface 411.

[0034] When designing client application 440, a user can specify how to create computer-executable instructions for code 441 via user interface 411. More specifically, user interface 411 can be used to create container hierarchy 200, the container information shown in FIG. 3, and code 441 that defines and implements various embodiments described herein. Information defining container hierarchy 200, the container information shown in FIG. 3, and various embodiments described herein can be stored in hardware memory 420, database 430, the computer executing client application 440, and / or computer-executed tool 410 as part of the design of the client application and associated code. During runtime execution, created code 441 can access this information to provide various embodiments. Additionally, client application 440 and associated code 441 communicate with and execute one or more server applications during execution. Pages of containers 231, 241, and 242 are displayed in user interface 442 as a result of execution of code 441. As described herein, the pages of containers 231 , 241 and 242 are displayed in a browser, for example, in response to a URL entered by a user into a browser running on a computer that communicates with client application 440 .

[0035] The tool 410 provides a "declarative system" that hides much of the complexity of creating computer instructions for code 441, for example, by providing boxes and arrows that can be dragged and dropped, as well as data entry fields. The declarative functionality allows unskilled programmers to create containers, container hierarchies, behavior chains, and events, and to specify behavior chains that are triggered by specific events using visual representations such as boxes and arrows. More specifically, containers can be represented using boxes and names entered into data entry fields. As shown in Figure 2, boxes nested within boxes can represent containers nested within containers. Lines or arrows can be used to specify the phases of a particular container's lifecycle that trigger behavior chains. This can be done at design time. The underlying computer-executable code 441 can then be executed during the execution of the client application. These developers are called "declarative developers" or "declarative programmers." Declarative developers do not have access to advanced programming techniques.

[0036] State is managed through a combination of containership and persistence. A container configuration is shown in Figure 3. A container acts when a variable (also called "state") is active. Persistence refers to the period of time that a variable remains. Various types of scope determine the level or type of persistence. As described herein, scope illustratively includes session scope, device scope, and history scope.

[0037] With session scope, when you exit a page in the same browser tab, the page's variables are discarded. However, when you return to that page, as long as it remains in the same browser tab, the same variables are restored. The variables can be stored in the browser's session storage. Therefore, the variables persist as long as the browser is open.

[0038] With device scope, when you close the browser tab, the page's variables are discarded. If you return to a similar page days later, these variables are restored. The variables can be stored in the browser's local storage. Thus, even if the browser is closed, the variables persist on the device running the application. Device scope is also known as "local scope."

[0039] History scoping allows a user to view the value of a variable as they navigate between pages in a client application. For example, the variable value is saved in the browser's history. When you use the browser's back button to return to a page in the browser history or refresh the page, the variable value is restored to the value it had when you left the application.

[0040] According to various embodiments, scopes can be used to mimic browser behavior, such as session persistence, history state, etc. For example, a session scope can be used to provide session persistence, and a history scope can be used to provide history state.

[0041] 2, if the receipt page container 242 modifies variables of containers that are shared between the receipt page container 242 and other containers, the other containers have access to these modifications. For example, if the receipt page container 242 modifies variable X of the SaaS cloud module container 220 and variable Y of the application container 210, the employee page container 231 also has access to the modifications to variables X and Y. In this example, this is because both the receipt page container 242 and the employee page container 231 reside in containers 220 and 210, and containers 220 and 210 are associated with the hierarchical paths 261 and 262 of both the receipt page container 242 and the employee page container 231.

[0042] According to one embodiment, a client application displays only one page at a time. Therefore, changes to variable values ​​associated with one hierarchical path do not conflict with changes to variable values ​​associated with another hierarchical path. More specifically, continuing the example with reference to FIG. 2, pages 242 and 231 both access variables X and Y, which belong to containers 220 and 210, respectively, but no conflict occurs because only one of pages 242, 231 is displayed at a time. Therefore, pages 242 and 231 cannot simultaneously change the values ​​of variables X and Y.

[0043] Two different copies of a client application can each display a different page. For example, with reference to FIG. 4, assume there are two copies of client application 440, each displaying a different page. If both pages change the value of variable X in the SaaS cloud module container, the database The process 430 resolves the conflicts as part of submitting the changes to the database 430 .

[0044] Each container can initiate one or more operation chains, and one or more operation chains can be initiated and executed in parallel during a lifecycle phase. For example, referring to Figure 2, the operation chains of SaaS cloud module container 220 and financial module container 240 can be executed simultaneously.

[0045] Because each lifecycle phase of a particular container executes mutually exclusively, the chains of operations for different lifecycle phases of a particular container do not execute in parallel. More specifically, with reference to FIG. 2, when the receipt page container 242 executes the "beforeEnter" lifecycle phase, If 20 action chains are started during the lifecycle phase, those 20 action chains will finish before the "enter" lifecycle phase of the receipt page container 242. .

[0046] An action chain in a container can initiate or cause the execution of another action chain in the same container. Also, an action chain in one container can initiate or cause the execution of action chains in containers along a hierarchical path. For example, with reference to FIG. 2, the action chain in receiving page container 242 can initiate or cause the execution of action chains associated with containers 252, 240, 220, and 210 along hierarchical path 261.

[0047] Because lifecycle phases are events, they can trigger chains of actions. For example, the lifecycle phase "Enter" for a particular container can trigger one or more actions. This can trigger a chain of actions.

[0048] An operation chain can start multiple child operation chains that run in parallel, which can then be combined.

[0049] According to one embodiment, the hierarchical path corresponds to a URL that a user enters into a browser to display a page in the user interface of client application 440. For example, with reference to Figures 2 and 4, hierarchical path 261 corresponds to a URL that specifies " / SaaSCloud / Financials / receipts." More specifically, when a user enters this URL into a browser, the first backslash causes the computer-executable instructions of code 441 to launch application container 210. The "SaaSCloud" portion of the URL causes The computer-executable instructions in code 441 launch the SaaS cloud module container 220, the "Financials" portion of the URL causes the computer-executable instructions in code 441 to launch the financial module container 240, and the "receipts" portion of the URL causes the computer-executable instructions in code 441 to launch the receipt page container 242 and load the corresponding receipt page. Similarly, hierarchical path 262 corresponds to a URL specifying " / SaaSCloud / HumanResources / Employee", and hierarchical path 263 corresponds to a URL specifying " / SaaSCloud / Financials / ExpenseReport".

[0050] The state of each container is created and destroyed based on the lifecycle associated with each container. Using the design-time user interface 411 of the tool 410, the developer can specify the lifecycle events that trigger the creation and destruction of each container's state. For example, the "beforeEnter" lifecycle event is associated with the expense report page. The "beforeExit" lifecycle event can trigger the creation of the state of the Expense Report Page Container 241, and the "beforeExit" lifecycle event can trigger the destruction of the state of the Expense Report Page Container 241. The lifecycle events that trigger the creation of the state may vary depending on the container. For example, the creation of the state of one container may be triggered by "beforeEnter", but The creation of another container state is triggered by "Enter". The lifecycle events that trigger may vary depending on the container.

[0051] Furthermore, the creation and destruction of the state of each container follows a hierarchical path. For example, with reference to Figures 2 and 4, if a user enters the URL " / SaaSCloud / Financials / ExpenseReport" into a browser on a computer running client application 440, In this case, the backslash starts the application container 210. The state of the application container 210 is created in response to lifecycle events specified by the developer using the design-time user interface 411. The "SaasCloud" portion of the URL is , initiates the SaaS cloud module container 220. The state of the SaaS cloud module container 220 is created in response to a lifecycle event that the developer specifies for the container 220 using the design-time user interface 411. Similarly, the states corresponding to the financial module container 240 and the expense report page container 241 are created in response to a lifecycle event that the developer specifies for the corresponding containers 240, 241. Also, if a user enters the URL " / SaasCloud / HumanResources / Employee," the destruction of the state of the expense report page container 241 and the state of the financial container 240 is triggered in response to a lifecycle event that the developer specifies for the corresponding containers 241, 240 using the design-time user interface 331. The creation of the states of the human resources module container 230 and the employee page container 231 is triggered in response to a lifecycle event that the developer specifies for the corresponding containers 230, 231. Because both hierarchical paths 262, 263 corresponding to the URLs share the application container 210 and the SaaS cloud container 220, the states of the containers 210, 220 are maintained. Each container can access the state of the container that contains it. For example, container 220 can access the state of container 210. Container 240 can access the states of containers 220 and 210. Container 241 can access the states of containers 240, 220, and 210. However, each container cannot access the state of a container that does not contain it. For example, containers 240 and 241 cannot access the states of containers 230 and 231, and vice versa.

[0052] A snapshot of the global variables used by the behavior chains is taken at the start of each behavior chain, for example if one parent behavior chain starts two child behavior chains, three snapshots will be taken.

[0053] Snapshots of the global variables used by an operation chain are taken when the operation chain begins execution. For example, three snapshots of each operation chain are shown in Figure 5A.

[0054] 5A illustrates operation chains 510, 520, and 530 executing in parallel, according to one embodiment. While functions or operation chains are described as executing "in parallel," as is well known, the concept of parallel execution is generally used to describe time-sliced ​​processing performed using a single processor, executing only one operation chain at a time at the micro-execution level. However, at a higher macro-execution level, e.g., the application instruction level, the operation chains are considered to operate simultaneously or in parallel. In general, the embodiments described herein may be applied to any execution scheme, e.g., single- or multi-processor architectures, multi-threaded processing, multi-pipelined processing, time-shared processing, distributed processing, or network (e.g., cloud) processing.

[0055] The operation chain 510, 520, 30 is a series of operations 511, 512, 521 to 525, and 531-533. Boxes represent operations 511, 512, 521-525, and 531-533, and arrows represent the flow of control from one operation to another in each operation chain. For example, execution occurs along the direction of the arrows. Operations can be executed sequentially in an operation chain, as indicated by the first and second boxes connected by arrows. Operations can also be executed in parallel, as indicated by the three boxes 522-524 in the second operation chain 520. More specifically, the first operation 521 in the second chain 520 may branch into three parallel operations 522-524, which are then combined with the subordinate operation 525. Alternatively, one or more operations may be executed conditionally so that not all operations in a chain are executed when one operation chain is invoked. One or more operations may be child operations of a previous operation. For example, the first action 521 of the second action chain 120 is a parent action, and the three actions 522 to 524 branching from it are child actions. In another example, action 511 is a parent action of action 512, and action 531 is a parent action of action 533.

[0056] Actions can perform various types of processing. For example, one action can read a value from a variable. Another action can write a value to a variable. In another example, one might want to retrieve several stock prices below a certain threshold and provide an alert if any of the stock prices fall below the certain threshold. In this case, an action branches to several other actions, each of which retrieves the stock prices in parallel. Once the stock prices are retrieved, these actions are combined into one action that determines which stock prices are below the threshold and provides that information as an alert. In yet another example, a web page can be designed to allow a user to purchase several songs by selecting a "Buy" button below each song displayed as a list. Selecting the "Buy" button triggers an event that initiates an action. Each action can process the purchase in parallel.

[0057] According to various embodiments, each operation chain is isolated from one another by partitions 541, 542, 543 (also called "isolation"), as indicated by the lines separating the operation chains. In other words, each operation chain has a private view of the state at the time of execution. For example, Y represents the global state. Illustratively, the state includes variables and data streams. Each operation chain has its own private view of the global state when it begins execution. For example, Y1 is a private view of Y's first operation chain, Y2 is a private view of Y's second operation chain, and Y3 is a private view of Y's third operation chain.

[0058] In one embodiment, views Y1, Y2, and Y3 can be realized using local variables in each of the isolations 541, 542, and 543 of the three operation chains 510, 520, and 530. Thus, each operation chain 510, 520, and 530 does not modify the global state Y, but can modify each of its local variables Y1, Y2, and Y3. In effect, the snapshot of global state Y created becomes a snapshot of the original state of Y1, Y2, and Y3, so if one operation chain has a bug, the state of that operation chain can be restored to its starting state for debugging purposes. Views Y1, Y2, and Y3 represent versions of state Y and are examples of mutable state because they can be modified by each operation chain. Operation chains are examples of processes. Y3 was created at a different time than Y1 and Y2. Thus, in operation 531 of the third operation chain 503, only Y is read, so the value of global variable Y is used. In operation 532, global variable Y is written. Because a local copy Y3 was created before writing the global variable Y, Y3 is written instead of Y. Therefore, in one embodiment, local variables are created dynamically. In one embodiment, at the end of the chain of operations 560, a conflict resolution 570 is performed to determine the new value of the global state Y from the final values ​​of Y1, Y2, and Y3. In one embodiment, the last written variable Y1, Y2, or Y3 is the one that is written to the global state. is the new value of the variable state Y.

[0059] FIG. 5B is a diagram illustrating an implementation of snapshots, according to one embodiment. A snapshot of the global variables used by the operation chains is taken when the operation chain begins execution. Figure 5B shows an example of three wrappers, i.e., 501, 502, and 503a / 503b, for each of the operation chains 510, 520, and 530 shown in Figure 5B. Assume the global variables are X, Y, and Z. In this example, for each of operation chains 510, 520, and 530, a wrapper or proxy is used to interface with global variables X, Y, and Z. For example, a wrapper or proxy is used to isolate private views Y1, Y2, and Y3 corresponding to the three operation chains from the global state Y. For operation chain 30, wrapper 3053a creates a local copy of global variable X, i.e., local copy X3, but does not create copies of global variables Y and Z because Y and Z are read-only at this point. Therefore, wrapper 503a passes the values ​​of Y and Z. Then, when writing Y, wrapper 503b (in this embodiment, wrappers 503a and 503b are similar wrapper code executed at different times) creates a local copy Y3. Operation chain 530 uses local copy X3 of X at this point (operation chain 532), but passes Z through because Z is read-only. The wrapper or proxy provides an association relationship between the shared variable Y and the private views Y1, Y2, and Y3. Based on this association relationship, implicit computer-executable instructions for modifying Y1, Y2, and Y3 can be used to replace explicit computer-executable instructions for modifying Y during runtime execution of operation chain 251 corresponding to client application 250.

[0060] Similarly, X1, X2, and X3 provide a private view of their respective operation chains to the global variable X. Z1 and Z2 provide a private view of their respective operation chains to the global variable Z.

[0061] For purposes of illustration, Figure 5B shows three sets of variables X, Y, and Z for three snapshots. Because X, Y, and Z are global variables of the client application, X in each set is a similar variable, Y in each set is a similar variable, and Z in each set is a similar variable.

[0062] Snapshots and associated wrappers can be nested. For example, if a first operation chain starts another operation chain, two snapshots are taken. The first snapshot is a snapshot of the parent operation chain, and the second snapshot is a snapshot of the child operation chain. The second snapshot is nested within the first snapshot. As an example, if an operation chain starts two other operation chains, three snapshots are taken.

[0063] The behavior chain can read and write global variables X, Y, and Z through explicit computer-executable instructions specified by the client application developer, and can replace the execution of these explicit computer instructions with the execution of the appropriate implicit computer instructions by redirecting these operations to the appropriate private view. For example, the explicit computer-executable instruction Y=Y+1 can be replaced with an implicit computer instruction by creating a wrapper, retrieving the locally stored private view Y1, and assigning Y the value of Y, making Y1=Y1+1.

[0064] According to one embodiment, a snapshot of only the variables that are changed is taken, but not read. No snapshots of read-only variables are taken.

[0065] According to one embodiment, a private view of a global variable is created immediately before the global variable is changed.

[0066] According to one embodiment, a private view is created by copying a global variable into a wrapper. By tracking changes to the variable, the state of the changed variable can be determined. The private view can be created in detail until the corresponding global variable is read or changed by another process.

[0067] The pages shown in Figures 6-18 are part of the tool's UI 411. The state management persistence user interface is part of the tool's user interface 411. The router configuration user interface is also part of the tool's user interface 411. The user interface 411 generates computer-executable instructions at design time that are part of the code 441 that is executed at run time for the client application.

[0068] A developer customizes the page using UI 411 of design tool 410. Figure 6 shows a screenshot of a page 600 for creating an action chain for a button that is part of UI 442, according to one embodiment. A description section can be added.

[0069] Page 600 can be displayed by selecting the "Start My Action Chain" tab 680. Page 600 of UI 411 includes, on the left side, a palette 610 of actions that can be added to action chain 640. A central section 620 of page 600 shows a flow diagram representing the sequence of one or more actions in action chain 640. Diamonds 641 represent "IF" statements or branching conditions for determining multiple alternative paths that can be selected when executing action chain 640.

[0070] 6, the palette 610 has three sections 650, 660, 670 labeled "General," "Logic," and "Navigation." Each section 650, 660, 670 contains icons representing actions that can be dragged and dropped into the center section 620 to create an action chain 640.

[0071] The general section 650 has three rows of icons. The first icon 651 in the first row of the general section represents a variable assignment. For example, this icon 651 can be used to set a variable to a different value. The second icon 652 in the first row represents an action chain invocation. This icon allows a developer to invoke another action chain from this action. The third icon 653 in the first row represents a component method invocation. This icon allows a developer to determine the UI component, for example, a button, that will be invoked on the page created for UI 442.

[0072] The second row of the General section contains three icons. The first icon 654 in the second row is a "Call Module Function" icon. This icon allows developers to define their own functions in JavaScript for pages created for UI 442. The "Call Module Function" icon allows developers to write code to call these functions. The second icon 655 in the second row is a "Call REST Endpoint" icon. This icon allows developers to write code to call REST endpoints to update or request data.

[0073] The third row of the general section 650 contains two icons. The first icon 657 in the third row is a "Start Notification" icon. This icon can be used to display a message on the page that the behavior chain is being implemented with. The second icon 658 in the third row is a "Reset Variables" icon. This icon can be used to reset the state values ​​to their default values.

[0074] The logic section 660 contains three icons 661-663. This section can be used to create logic flow in your action chain. The first icon 661 in the logic section represents an "IF" conditional action. The second icon 662 in the logic section represents a switch. The third icon 663 in the logic section represents a return. The third icon 663 is used at the end of an action chain and can return a specific result or value. The third icon 663 is useful when calling another action chain from one action chain.

[0075] Navigation section 670 includes three icons 671-673. A developer can use first icon 671 in the navigation section to create code that navigates to a previous page. In this case, the previous page is a previous page in the browser history of client computer 450. A developer can use second icon 672 in the navigation section to create code that, when executed, navigates to a page in client application 650. For example, icon 672 can be used to create computer-executable code that navigates from an expense report page in client application UI 442 to an employee page in client application UI 442. A developer can use third icon 673 in the navigation section to create code that navigates to a URL that does not exist in the currently running client application 450.

[0076] Actions can be associated with phases of a container by selecting tabs representing items such as web applications, pages, and action chains. The developer can then navigate to the settings panel within the page. Figure 7 shows a screenshot of a settings panel page 700, according to one embodiment.

[0077] 8 illustrates a web page 800 for associating a lifecycle event with a user interface component according to one embodiment. A developer can associate a lifecycle event by selecting the lifecycle event, e.g., "beforeEnter" 801, from a list 810 shown in the screenshot of page 800. Cut.

[0078] 9 shows a web page 900 for generating a verification code according to one embodiment. A developer can use page 900 to generate code that, when executed on the user interface 442 of a client application being created, will verify that users can view the page. A user can select option 901 to enter a verification code.

[0079] 10 illustrates a web page 1000 for selecting an action chain, according to one embodiment. A developer can select an action chain to be invoked in response to a selected lifecycle event from web page 800 (FIG. 8). For example, page 1000 illustrates a "My Action Chains" 1001 that a developer can select under a "Page Action Chains" tab 1002. Page 1000 also provides an "Application Action Chains" tab 1003.

[0080] 11 shows a web page 1100 that a developer can use to map input parameters required for an action chain using the page, according to one embodiment. For example, a developer can click on "Input Parameters" 1101 shown below "My Action Chain" 1103 to map input parameters to a selected action chain shown as "My Action Chain" above fields 1101 (FIG. 11) and 1001 (FIG. 10).

[0081] Referring to page 1100 , an action chain has an identifier (ID) that may be specified in an action chain ID field 1102 .

[0082] 12 illustrates a web page 1200 that a novice developer can use to associate a UI component with a component event, according to one embodiment. For example, the developer can drag a UI component from a palette 1210 on the left side to a center pane 1220. In this example, the dragged UI component is a button 1221. In response, the developer selects the actions tab 1230 shown in FIG. 12, and a list of events is displayed. The developer can select an event to associate with the UI component 1221 displayed in the center pane 1220.

[0083] Additionally, the developer can click on a representation of a UI component, such as button 1221, to display the attributes of that UI component.

[0084] Figure 13 illustrates a web page 1300 that includes an event list 1310, according to one embodiment. When a developer selects the actions tab 1230 shown on page 1200, the event list 1310 is displayed as shown in Figure 13. The developer can select an event from those displayed in Figure 13 and associate it with a UI component, such as button 1221, displayed in the center pane 1220.

[0085] Additionally, the developer can click on a representation of a UI component, such as button 1221, to display the attributes of that UI component.

[0086] When a developer clicks on the actions tab 1230 of page 1200 of Figure 12, the developer is responsively presented with an events list 1310, as shown in Figure 13. The developer can select an event from the displayed list 1310 to associate with a UI component. In the illustration, this UI component is button 1221, which the developer previously selected from web page 1200 (Figure 12).

[0087] The event list 1310 may include, for example, an "unclick" event that occurs when a non-primary pointing device button is pressed and released on an element, a "bokeh" event that occurs when the keyboard is not focused on an element, a "click" event that occurs when a primary pointing device button is pressed and released on an element, a "context menu" event that occurs when a context menu associated with an element is invoked, a "double click" (dbclick) event that occurs when a pointing device button is clicked twice on an element, and a "click" event that occurs when a context menu associated with an element is invoked. or a text selection while continuing to drag it; a "drag end" event that occurs when dragging an element or text selection ends (by releasing the pointing button or canceling the drag operation); and a "drag confirmed" event that occurs when the dragged element or text selection is moved over a valid drop target.

[0088] Referring to FIG. 4, the tool's user interface 411 is shown creating a button on the user interface 452 of the client application 450. Embodiments are well suited to other types of user interface controls, such as drop-down menus, tabs, menus, radio buttons, lists, etc. As described herein, a user's interaction with a user interface control can directly or indirectly trigger an action chain.

[0089] 14 shows a property inspector 1400 for specifying input parameters 1401, according to one embodiment. Through the property inspector 1400, a user can provide an identifier (ID) 1404 and a page 1405.

[0090] A developer may use an action chain on multiple pages of an application they are creating, for example, a developer may create an application-scoped action chain when navigating to the start page.

[0091] When a developer adds a "Page Navigation" action to an action chain 640 (Figure 6), 1403 (Figure 14), the developer can specify an input parameter 1401 (Figure 14) to specify the ID of the record. A developer can add a "Page Navigation" action to an action chain by doing the following: 1. Open the page behavior editor, 2. Click on an action chain in the list to open it in the Action Editor. 3. Drag the "Page Navigation" icon 672 (FIG. 6) from the Actions Palette into the action chain 640 (FIG. 6), 1403 (FIG. 14).

[0092] A developer can drag an action onto the add (+) icon 681 (FIG. 6), 1402 (FIG. 14) in the action chain 640 (FIG. 6), 1403 (FIG. 14). Typically, this action is the last action in the chain. When a developer adds a "Page Navigation" action to an action chain, the Property Inspector 1400 opens it in an editor.

[0093] FIG. 15 shows a property inspector 1500 with page selection buttons 1501 according to one embodiment.

[0094] 4. Click the "Select Page" button 1501 in the Property Inspector 1500.

[0095] 16 illustrates a "Select Pages" dialog box 1600 showing a list of pages 1601 in an application 440 (FIG. 4) that a developer is creating, according to one embodiment. Dialog box 1600 is displayed in response to the developer clicking the "Select Pages" button 1501 in property inspector 1500 (FIG. 15).

[0096] 5. Select a page from the list 1601. Click the "Select" button 1602. If the page the developer selected has input variables, the developer can map the page variables to the input parameters of the action.

[0097] FIG. 17 illustrates a property inspector 1700 for specifying the name of an action, according to one embodiment.

[0098] 6. Enter a name for the behavior in the ID field 1701 of the Property Inspector 1700. Selecting a behavior from the canvas allows the developer to edit the properties of that behavior in the Property Inspector.

[0099] 7. Optionally, if the page uses input parameters, map the input value page variables to the action's parameters by clicking the input parameter's arrow (+) icon 1702 and click Save.

[0100] 18 illustrates a dialog box 1800 for mapping variables to parameters, according to one embodiment. In the "Map Variables to Parameters" dialog box 1800, a developer can map sources to targets by dragging variables in a "Source" panel 1810 to parameters in a "Target" panel 1820. A developer can click on a parameter name to view the expression for the mapped variable. Line 1830 represents the mapping between "My Contact ID" in the "Source" panel 1810 and "Contact ID" in the "Target" panel 1820. While the illustration shows a mapping between "My Contact ID" and "Contact ID," embodiments are suitable for mapping other variables to other parameters.

[0101] If a suitable variable does not exist, the developer can create it in the Variables editor and then edit the behavior.

[0102] 8. If desired, specify other parameters that may be used in the operation. Regarding the "Page Navigation" action (see icon 672 in FIG. 6), the action module for this action is "vb / action / builtin / navigateToPageAction." This action navigates the client application's UI 442 (FIG. 4) and performs parameter passing to activate the page. According to one embodiment, the parameters for this action are as follows:

[0103] [Table 1]

[0104] According to one embodiment, page parameters are similar to variables marked as input. When invoking an action, the variables of the destination page can be passed internally or via the URL. The framework arranges for the parameters to end up in the correct place and be passed to the destination page.

[0105] The following codes are entered via UI 411 and become part of code 441:

[0106] [Table 2]

[0107] If there are no errors during navigation, the result "Success" is returned. If navigation is successful, the result "true" is returned, otherwise the result "false" is returned. If an error occurs, the result "Failed" is returned with a payload containing the error. The result "Loss" is returned.

[0108] Exemplary Methods Figure 19 is a flow chart illustrating a method for providing state management persistence according to one embodiment. The method of Figure 19 and the dependent claims are described below for state management persistence. The claims are set forth at the end of this application.

[0109] The method 1900 begins at step 1910 . In step 1920, a user interface of the design-time tool receives a container hierarchy that includes a container nested inside one or more other containers, each container containing a different portion of the web client application.

[0110] For example, a junior developer may enter container hierarchy 200 (FIG. 2) into user interface 411 of design-time tool 410. Each container in container hierarchy 200 is nested inside one or more other containers and contains a different portion of web client application 440.

[0111] In step 1930, a design-time tool is used to associate a state with each container in the container hierarchy.

[0112] For example, a junior developer can enter variables 321 and 351 (FIG. 3) into the tool's UI 411, and the tool 410 (FIG. 4) can associate variables 321 and 351 (FIG. 3) with corresponding containers 310 and 340 (FIG. 3).

[0113] In step 1940, the user interface of the design-time tool Receive lifecycle.

[0114] For example, a junior developer can enter lifecycles 323 and 353 (FIG. 3) for each container shown in FIG. 2 into user interface 411 (FIG. 4) of design-time tool 410.

[0115] In step 1950, design-time tools are used to create computer-executable instructions for the web client application that enable it to create and destroy the state of each container according to the hierarchy and based on each container's lifecycle.

[0116] For example, as described herein, computer-executable instructions 410 that enable the creation and destruction of the state 321 and 351 of each container shown in FIG. 2 are created for web client application 440 based on the lifecycle 323 and 353 of each container according to hierarchy 200.

[0117] More specifically, according to one embodiment, the hierarchical path corresponds to a URL that a user can enter into a browser to display a page in the user interface of client application 440. For example, with reference to Figures 1, 2, and 4, hierarchical path 261 corresponds to URL 130, which specifies " / SaaSCloud / Financials / receipts." When a user enters URL 130 into a browser, the initial backslash 100 causes the computer-executable instructions in code 441 to launch application container 210. The "SaaSCloud" portion 101 of URL 130 causes the computer-executable instructions in code 441 to launch application container 210. The instructions launch the SaaS Cloud module container 220, and the "Financials" portion 102 of the URL 130 causes the computer-executable instructions in code 441 to launch the financial module container 240, and the "receipts" portion 133 of the URL 130 causes the computer-executable instructions in code 441 to launch the receipt page container 242 and load the corresponding receipt page. Similarly, hierarchical path 262 corresponds to a URL specifying " / SaaSCloud / HumanResources / Employee", and hierarchical path 263 corresponds to a URL specifying " / SaaSCloud / Financials / ExpenseReport".

[0118] The state of each container is created and destroyed based on the lifecycle associated with each container. Using the design-time user interface 411 of the tool 410, the developer can specify the lifecycle events that trigger the creation and destruction of each container's state. For example, the "beforeEnter" lifecycle event is associated with the expense report page. The creation of a state 351 for a container 241 can be triggered by a "beforeExit" lifecycle event, and the destruction of a state 351 for an expense report page container 241 can be triggered by a "beforeEnter" lifecycle event. The lifecycle events that trigger the creation of a state can vary depending on the container. For example, the creation of a state for a container can be triggered by a "beforeEnter" lifecycle event. The creation of another container state is triggered by "Enter". The lifecycle events that trigger the destruction of state may vary from container to container.

[0119] Furthermore, the creation and destruction of the state of each container follows a hierarchical path. For example, with reference to Figures 1, 2, and 4, suppose a user types the URL " / SaaSCloud / Financials / ExpenseReport" into the browser of a computer that communicates with client application 440. If you enter 0, the backslash 100 starts the application container 210. The creation of the application container 210 state 321 is triggered in response to a lifecycle event specified by the developer using the design-time user interface 411. The "SaasCloud" portion 101 of the URL 110 starts the SaaS Cloud module container 210. 220. The creation of the state 321 of the SaaS cloud module container 220 is The creation of the states 321, 351 corresponding to the financial module container 240 and the expense report page container 241 is triggered in response to a lifecycle event that the developer specified for the container 220 using the design-time user interface 411. Similarly, the creation of the states 321, 351 corresponding to the financial module container 240 and the expense report page container 241 is triggered in response to a lifecycle event that the developer specified for the corresponding containers 240, 241. Also, if a user enters the URL 120 " / SaasCloud / HumanResources / Employee", the destruction of the state 351 of the expense report page container 241 and the state 321 of the financial container 240 is triggered in response to a lifecycle event that the developer specified for the corresponding containers 241, 240 using the design-time user interface 411. The creation of the states 321, 351 of the human resources module container 230 and the employee page container 231 is triggered in response to a lifecycle event that the developer specified for the corresponding containers 230, 231. Because both hierarchical paths 262, 263 corresponding to URLs 120, 110 share the application container 210 and the SaaS cloud container 220, the state of the containers 210, 220 is maintained.

[0120] Each container can access the state of the container that contains it. For example, container 220 can access the state of container 210. Container 240 can access the states of containers 220 and 210. Container 241 can access the states of containers 240, 220, and 210. However, each container cannot access the state of a container that does not contain it. For example, containers 240 and 241 cannot access the states of containers 230 and 231, and vice versa.

[0121] In step 1960, design-time tools are used to provide each container with access to its own state and the state of any containers that enclose it, based on the lifecycle events associated with each container.

[0122] For example, container 220 can access the state of container 210. Container 240 can access the state of containers 220 and 210. Container 241 can access the state of containers 240, 220, and 210. However, each container cannot access the state of a container that does not contain it. For example, containers 240 and 241 cannot access the state of containers 230 and 231, and vice versa.

[0123] Additionally, a container can access these states based on corresponding lifecycle events. As described herein, for example, a container 241 may access these states based on the occurrence of a developer-specified lifecycle event, such as "beforeExit" or "canExit." Until the container is closed, it can access its own state and the state of other containers that contain it.

[0124] The method ends at step 1970. One embodiment provides for receiving, in a user interface, details of a first event in a first lifecycle of a first container and associating the first event with the creation of a state for the first container, and receiving, in a user interface, details of a second event in a second lifecycle of a second container and associating the second event with the creation of a state for the second container.

[0125] For example, one embodiment may include receiving details of a first event, such as "beforeEnter," in a first lifecycle 353 of a first container 241 at a user interface 411. and associating the first event with the creation of the state 351 of the first container, and in the user interface, creating a second lifecycle 353 of the second container 242. receiving details of a second event, such as "Enter" that The lifecycle events that trigger state creation may vary depending on the container. For example, one container's state creation may be triggered by "beforeEnter", while another's state creation may be triggered by "Enter". Also, the lifecycle events that trigger state destruction may vary depending on the container.

[0126] In one embodiment, the first event and the second event are different types of events. As an example, the first event is "beforeEnter," which is different from the second event "Enter." Both events can trigger the creation of different container 241, 242 states.

[0127] One embodiment provides for receiving, in a user interface, details of a first event in a first lifecycle of a first container and associating destruction of the state of the first container with the first event, and receiving, in a user interface, details of a second event in a second lifecycle of a second container and associating destruction of the state of the second container with the second event. For example, one embodiment provides for receiving, in a user interface 241, details of a first event, such as "beforeExit," in a first lifecycle 353 of a first container 241 and associating destruction of the state 351 of the first container 241 with the first event, and receiving, in a user interface, details of a second event, such as "canExit," in a second lifecycle 353 of a second container 242. The "beforeExit" lifecycle event triggers the destruction of the state 351 of the expense report page container 241. The "canExit" lifecycle event provides for receiving the expense report page details and associating the destruction of the state 351 of the second container 242 with the second event. The "beforeExit" lifecycle event triggers the destruction of the state of the expense report page container 241. triggers the discarding of the state of receipt page 242.

[0128] In one embodiment, the first event and the second event are different types of events. As an example, "beforeExit" and "canExit" are two different types of events. be.

[0129] One embodiment provides for, in response to navigating from a first container to a second container during execution of a web client application, discarding a state of the first container, saving a state of a third container, creating a state of the second container, and providing the second container with access to the saved state of the third container, where both the first container and the second container are contained within the third container, and the navigation triggers a lifecycle event of the first container.

[0130] For example, one embodiment provides for responsive to navigating from a first container 240 to a second container 230 while a web client application 210 is running, discarding the state of the first container 240, saving the state of a third container 220, creating a state for the second container 230, and providing the second container 230 with access to the saved state of the third container 240. Both the first container 240 and the second container 230 are contained within the third container 220, and the navigation triggers a lifecycle event for the first container 240. This is just one example; another example is the first container 220, the second container 250, and the third container application 210.

[0131] One embodiment provides for associating containers with portions of a uniform resource locator (URL) pattern, with each portion of the URL pattern associated with a respective container. Figure 2 shows the containers associated with the portions of the URL pattern shown in Figure 1. .

[0132] In one embodiment, each portion of a URL pattern maintains a corresponding lifecycle. For example, lifecycles 323, 353 (FIG. 3) are associated with each portion 100, 101, 102, 103 of URL 110 (FIG. 1). A lifecycle is associated with each portion of each URL.

[0133] One embodiment provides for executing portions of a container according to a hierarchical path associated with a URL pattern, creating variables of the container based on the URL pattern, and destroying variables of the container based on the URL pattern.

[0134] For purposes of explanation, assume the hierarchical path is 263. Some of the containers associated with hierarchical path 263 are 241, 240, 220, and 210. Variables for each container are created as execution proceeds from the outside to the inside along hierarchical path 263. For example, variables for containers 210, 220, 240, and 241 are created in order based on URL 110. Variables for each container are destroyed based on URL 110 as execution proceeds from the inside to the outside along hierarchical path 263. For example, variables for containers 210, 220, 240, and 241 are destroyed in order.

[0135] One embodiment provides a particular container with access to its variables and to the variables of containers that encompass it along a hierarchical path corresponding to the particular container. For example, container 242 can access its own variables and can access the variables of containers 240, 220, and 210 (FIG. 2).

[0136] FIG. 20 is a flow chart illustrating router configuration according to one embodiment. The method begins at step 2010 .

[0137] Step 220 provides a uniform resource locator (URL) pattern. According to one embodiment, the hierarchy paths correspond to URLs that a user can enter into a browser to display a page in the user interface of client application 440. For example, with reference to FIGS. 1 and 2, hierarchy path 263 corresponds to URL 110, hierarchy path 262 corresponds to URL 120, and hierarchy path 261 corresponds to URL 130. More specifically, when a user enters URL 130 into a browser, backslash 100 causes the computer-executable instructions of code 441 to start application container 210, and the "SaaSCloud" portion 101 of URL 130 causes code 441 to The computer-executable instructions in code 441 launch the SaaS cloud module container 220, and the “Financials” portion 102 of the URL 130 causes the computer-executable instructions in code 441 to launch the financial module container 240, and the “receipts” portion 133 of the URL 130 causes the computer-executable instructions in code 441 to launch the receipt page container 242 and load the corresponding receipt page.

[0138] Based on the URL pattern, step 2030 creates the relevant portion of the application. For example, and with reference to Figures 1 and 2, for purposes of explanation, assume that a user enters URL 110 into a browser on a computer that communicates with client application 440. The browser loads and displays the expense report page that corresponds to URL 110. Code 441 uses the lifecycle of the containers along hierarchical path 263 that correspond to URL 110 to determine when to create and destroy variables for those containers.

[0139] For example, the variables in the application container 210 are created when the browser starts the application 440 in response to encountering a backslash 100. The variables in the SaaS Cloud module container 220 are stored when the browser starts the SaaS Cloud module in response to detecting the "SaasCloud" portion 101 of the URL 110. The financial module container 240 variable is created when the browser finds the "Financials" portion 102 of the URL 110. The expense report page container 242 variable is created when the browser finds the "ExpenseReports" portion 103 of the URL 110.

[0140] In step 2040, the relevant portions of application 440 are discarded based on the URL pattern. For example, assume that a user enters URL 120 (FIG. 1) into a browser on a computer that communicates with client application 440 (FIG. 4). Referring to FIG. 2, the variables for receipt page container 242 and financial module 240 are discarded. The variables for personnel container 230 and employee page container 231 are created.

[0141] According to one embodiment, each container has a corresponding lifecycle. For example, variables can be created and destroyed in response to a phase of the lifecycle associated with the container. For example, a variable for a page can be created in response to the "beforeEnter" phase of the page's lifecycle and destroyed in response to the "beforeExit" phase of the same page's lifecycle. and is discarded.

[0142] The method for configuring a router ends at step 2050 . One embodiment provides for associating containers with portions of a URL pattern, with each portion of the URL having its own container. For example, as described herein, each container shown in Figure 2 is associated with a portion of the URL pattern shown in Figure 1.

[0143] One embodiment provides each container with a hierarchical path defined by the containers that contain the particular container and the order of the containers that contain the particular container. For example, each container shown in Figure 2 is associated with a hierarchical path 261-267. In a specific example, hierarchical path 263 for container 241 is defined by containers 240, 220, and 210 that contain container 241 and the order of the containers that contain the particular container 241. In this figure, the order of the containers is such that container 241 is located inside container 240, which is located inside container 220, which is located inside container 210.

[0144] One embodiment provides a particular container with access to its own variables and to the variables of containers along a hierarchical path that includes the particular container. For example, container 241 can access its own variables and can also access the variables of containers 240, 220, and 210. Container 240 can access its own variables and can also access containers 220 and 210. However, container 240 cannot access the variables of containers 241, 242, 230, and 231, for example.

[0145] In one embodiment, the lifecycle includes phases, including a "beforeEnter" page, an "enter" page, an "interactable" page, a "canExit" which means the page can be exited, and a "beforeExit" phase which occurs before exiting the page. .

[0146] In one embodiment, the phases are mutually exclusive, in other words, only one phase in the container's lifecycle can be active at a time.

[0147] In one embodiment, at least one phase is an event to initiate an action chain.

[0148] One embodiment provides for a design-time tool to receive user input that defines a portion of an application and to generate computer-executable instructions for the application based on the input. For example, UI 411 of design-time tool 410 can be used to receive user input and to generate computer-executable instructions 441 using the received input.

[0149] One embodiment provides for executing the generated computer-executable instructions when the application is run, e.g., generated computer-executable instructions 441 are executed during execution of application 440.

[0150] Also, as can be seen, the destruction and creation of variables is relative to the hierarchical path: for example, a container's variables are created as execution proceeds from the outermost to the innermost of a hierarchical path, and are destroyed as execution proceeds from the innermost to the outermost of a hierarchical path.

[0151] 1 and 2, computer-executable code corresponding to a container can access its own variables and the variables of containers along its hierarchical path. For example, receipt page container 242 can access its own variables and the variables of containers 240, 220, and 210 along hierarchical path 261.

[0152] According to one embodiment, the life cycle of a container is associated with the portion of the URL that corresponds to that container. For example, the life cycle of the receipt page container 242 is associated with the "ExpenseReports" portion 103 of the URL 110. The life cycle of the financial module container 240 is associated with the "Financials" portion 102 of the URL 110.

[0153] The router configuration user interface is part of the tool's user interface 411. At design time, the router configuration user interface generates computer-executable instructions that are part of the code 441 that is executed at run time for the client application.

[0154] Referring to FIG. 6, a first icon 671 and a second icon 672 under a navigation section 670 can be used to configure the router according to the methods described herein.

[0155] An action chain is a series of actions that a developer can create to define the behavior of a component. Action chains are triggered by events such as "click", "OnValueChanged", and "focus" that a developer adds to a page component. Action chains created in the "Behavior Editor" are only available to the specific page they are being created for, as shown in Figure 6.

[0156] Exemplary System FIG. 21 illustrates a system 2100 according to one embodiment.

[0157] The page lifecycle manager 2101 initializes and destroys parts of the state depending on the application UI the user is currently viewing. When destroying the state, the state can be saved to a persistence store (if configured), and when restoring the state, the state can be loaded from the persistence store.

[0158] The persistent store 2102 stores application data between invocations of the application by a user. This is where the session state is stored (on disk).

[0159] State 2103 provides the active state utilized by the application (variables).

[0160] The component 2104 provides a UI including buttons, text, images, etc. that are utilized by the user.

[0161] The operation chain 2105 provides the flow of the core logic that drives the application (process).

[0162] The REST service 2106 provides an external REST API. The computer / device 2107 provides a browser or device that controls the UI.

[0163] The flow of operations 2111 to 2121 related to entities 2101 to 2107 included in system 2100 will be described below.

[0164] Operation 2111: The persistent store initializes and saves state while the user is actively using the application.

[0165] Operation 2112: Reflect the state change in a component, for example, a text field associated with some state.

[0166] Operation 2113: A component triggers a change in state, e.g., a text input updates the state directly.

[0167] Operation 2114: The user interacts with the UI from his device 507. Operation 2115: The action chain may invoke a method on the UI, for example, to zoom the map.

[0168] Operation 2116: The UI can initiate an action chain to execute logic (eg, click a button).

[0169] Operation 2117: The operation chain is used to invoke REST services and write data to or read data from the system via these services.

[0170] Operation 2118: The page lifecycle manager initializes and destroys state as the user navigates through the application and different UIs are displayed.

[0171] Operation 2119: The page lifecycle manager can execute a chain of actions in response to a navigation. For example, a user interacting with the device 2107 can initiate a page, in response to which a chain of actions can be executed.

[0172] Operation 2120: Action chains can cause navigation, for example, activation of various parts of the UI.

[0173] According to one embodiment, a user interface created by the system 2100 can be executed in a browser on a client computer / device 2107. The client computer / device that executes the created user interface is the client computer / device 2107 that was used to create the user interface. The created user interface may be executed on multiple client computers / devices at different times or simultaneously.

[0174] A user interface is created using design-time tools as described herein. According to one embodiment, a JSON file is created as part of the user interface. The created JSON file is transferred via well-known communication methods to a browser on a client computer / device and interpreted by a runtime execution.

[0175] Regarding the change of delay state, according to one embodiment, the execution flow is as follows. Invokes an action chain (usually via 2116), which copies the state via 2121. When the action chain completes, it merges the state via 2121.

[0176] Regarding state management persistence, according to one embodiment, the flow of execution is as follows: When a portion of the UI is started (via 2116 and 2120), the page lifecycle manager (2101) initializes the state (2118). The page lifecycle manager can reference a persistent store (2111) to initialize the state.

[0177] Regarding router configuration, according to one embodiment, the execution flow is as follows: Once a portion of the UI is started (via 2116 and 2120), the page lifecycle manager initializes the state according to the portion of the UI indicated (via 2118).

[0178] According to one embodiment, the router is implemented in the operation chain 2105 shown in Figure 21 by an operation called a "page navigation" operation. As described herein, the router uses URLs to map variables (also called "state") of a container to parts of a URL.

[0179] Exemplary Computer Environment Figure 22 is a schematic block diagram illustrating a system 2200 and associated computing environment that can be used to implement the embodiments illustrated in the drawings herein. The exemplary system 2200 can support or execute the various hardware and / or software modules and associated methods described with reference to Figure 21. It should be noted that certain embodiments can be implemented using one or more standalone applications (e.g., resident on a user device) and / or one or more web-based applications implemented using a combination of client-side and server-side code.

[0180] Generic system 2200 includes user devices 2260-2290, specifically, desktop computer 2260, notebook computer 2270, smartphone 2280, mobile phone 2285, and tablet 2290. Generic system 2200 can interface with any type of user device, such as a thin client computer, an Internet-enabled mobile phone, an Internet-connected mobile device, a tablet, an e-book reader, or a PDA capable of displaying and viewing web pages, other types of electronic documents and UIs, and / or running applications. As shown, system 2200 supports five user devices, but any number of user devices can be supported.

[0181] Web server 2210 is used to process requests from web browsers and standalone applications for web pages, electronic documents, enterprise data or other content, and other data from user computers. Web server 2210 also provides push or syndicated data related to the operation of the enterprise. The content can be provided as an RSS feed, for example.

[0182] The application server 2220 runs one or more applications. The applications may be written in a programming language such as Java, C, C++, C#, or a scripting language such as JavaScript or ECMAScript (European Computer Manufacturers Association Script), Perl, PHP (Hypertext Preprocessor), Python, Ruby, or TCL (Tool Command Language). Applications can be implemented as one or more scripts or programs written in a standard programming language such as Rails, Enterprise JavaBeans, or .NET. Web content can be created using HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and other web technologies, including template languages ​​and parsers. This can be done.

[0183] Data applications running on application server 2220 are configured to process input data and user computer requests and may store or retrieve data from data storage or database 2230. Database 2230 stores data created and used by the data applications. In one embodiment, database 2230 comprises a relational database configured to store, update, and retrieve data in response to SQL-formatted commands or other database query languages. Other embodiments may use unstructured data storage architectures and NoSQL (Not Only SQL) databases.

[0184] In one embodiment, application server 2220 includes one or more general-purpose computers capable of executing programs or scripts. In one embodiment, web server 2210 is implemented as an application running on one or more general-purpose computers. Web server 2210 and application server 2220 may be combined and may run on the same computer.

[0185] Electronic communications networks 2240 and 2250 enable communications between user computers 2260-2290, web server 2210, application server 2220, and database 2230. In one embodiment, networks 2240 and 2250 include any electrical or optical communications devices, such as wired network 2240 and wireless network 2250. Networks 2240 and 2250 may include one or more local area networks, such as an Ethernet network, a wide area network, such as the Internet, a cellular carrier data network, or a virtual network, such as a virtual private network.

[0186] System 2200 is an example for running applications in accordance with an embodiment of the present invention. In another embodiment, web server 2210, application server 2220, and optionally database 2230 may be combined into a single server computer application and system. In a further embodiment, virtualization and virtual machine applications may be used to implement one or more of web server 2210, application server 2220, and database 2230.

[0187] In yet another embodiment, all or part of the web and application functionality may be integrated into an application running on each user's computer, for example, a JavaScript application on the user's computer may be used to retrieve or analyze data and display parts of the application.

[0188] In certain exemplary embodiments, user computing devices 260-2290 execute, for example, a browser used to display the user interface. For example, the user interface may be viewed from client computing devices such as desktop computer 2260, notebook computer 2270, smartphone 2280, mobile phone 2285, and tablet 2290 shown in FIG. 22 and / or other computing devices.

[0189] In certain exemplary embodiments, browsers on desktop computer 2260, notebook computer 2270, smartphone 2280, mobile phone 2285, and tablet 2290 of FIG. 2 connect to the Internet, represented by wired network 2240 and / or wireless network 2250 shown in FIG. 22, to utilize one or more networked servers, databases, and / or associated cloud-based functionality represented by the modules of FIG. 21. For example, one or more entities 2101, 2104, 2105, and 2106 may reside on application server 2220. Client computer / device 2107 may be implemented as one or more user computing devices 2260-2290. One or more databases 2230 shown in FIG. 22 may be used to host data such as persistent store 2102 and state 2103 of FIG. 21. The network used in FIG. 21 may be implemented as network 2240. In one embodiment, network 2240 may be used to communicate between client computer / device 2107 and component 2104.

[0190] 4 and 22, network 470 may be wireless network 2250 or wired network 2240, or may include both wireless network 2250 and wired network 2240. Hardware memory 420 and / or database 430 may be implemented as data storage / database 2230. One or more applications 440, 450, 460 and tool 410 may reside on or be executed by one or more web servers 2210 or application servers 2220. UI 411 and 442 pages may be loaded and displayed by browsers running on user computing devices 2260-2290. Client application 440 may be executed within or by tool 410. Tool 410 and application 440 may run on the same computer or on separate computers that communicate with each other.

[0191] Figure 23 is a schematic block diagram illustrating a computing system 2300 that can be used to implement embodiments described herein. Although the computing system 2300 of Figure 23 is described as performing one or more steps of the embodiments described herein, in other embodiments, any suitable component or combination of components of the computing device 2300 or any suitable processor or combination of processors associated with the system 2300 can facilitate performance of the steps.

[0192] 23 illustrates a block diagram of an exemplary computing system 2300 that may be used in the embodiments described herein. For example, the computing system 2300 may be used to implement the user devices 2260-2290 and server devices 2210, 2220 of FIG. 22 and to perform the methods described herein. In some implementations, the computing system 2300 may include a processor 2302, an operating system 2304, memory 2306, and an input / output (I / O) interface 2308. In various implementations, the processor 2302 may be used to The various functions and features described herein can be implemented and the methods described herein can be performed. Although processor 2302 is described as performing the methods described herein, any suitable component or combination of components of system 2300 or any suitable processor or combination of processors or any suitable system associated with system 2300 can perform the methods described herein. The methods described herein may be performed on a user device, a server, or a combination of both.

[0193] Computing device 2300 also includes software application 2310, which may be stored in memory 2306 or any other suitable storage or computer-readable medium. The software application 2310 provides instructions that cause processor 2302 to perform the functions described herein and other functions. The components of computing system 2300 may be implemented by one or more processors or any combination of hardware devices, and any combination of hardware, software, firmware, etc.

[0194] 23 illustrates each of the processor 2302, operating system 2304, memory 2306, I / O interfaces 2308, and software applications 2310 as a single block. These blocks 2302, 2304, 2306, 2308, and 2310 may represent multiple processors, multiple operating systems, multiple memories, multiple I / O interfaces, and multiple software applications. In various implementations, the computing system 2300 may not include all of the components illustrated and / or may include other components instead of or in addition to the components illustrated.

[0195] Computer-Readable Media and Devices Unless otherwise specified, one or more embodiments described herein may be implemented using processor-readable instructions residing, for example, in a non-transitory processor-readable storage device of a computer system or similar device. The non-transitory processor-readable storage device may be any physical memory capable of storing instructions. Examples of non-transitory processor-readable storage devices include, but are not limited to, disks, compact discs (CDs), digital versatile devices (DVDs), read-only memory (ROM), flash, etc. As described above, some of the processes and operations of various embodiments of the present invention are, in one embodiment, implemented as a series of processor-readable instructions (e.g., software programs) residing in a non-transitory processor-readable storage device of a computer system and executed by one or more processors of the computer system. When executed, the instructions cause the computer system to perform the functions of various embodiments of the present invention. For example, a processor may execute instructions. The processor may be a hardware processor, such as a central processing unit associated with the computer system. The non-transitory processor-readable storage device may be hardware memory, and one or more processors may be hardware processors. According to one embodiment, the non-transitory processor-readable storage device is a tangible physical device.

[0196] conclusion Any suitable programming language can be used to implement the routines of particular embodiments, including C, C++, Java, assembly language, etc. Different programming techniques can be used, for example, procedural or object-oriented programming techniques. The routines can be executed on a single processing unit or multiple processors. Although steps, actions, or operations are described in a particular order, this order may be changed in different particular embodiments. In some particular embodiments, the routines described herein Furthermore, steps that are performed sequentially may be performed simultaneously.

[0197] Certain embodiments may be implemented in a computer-readable storage medium for use by or in connection with an instruction execution system, machine, system, or device. Certain embodiments may be implemented in the form of control logic in software or hardware, or a combination of both. This control logic, when executed by one or more processors, is operable to perform those described in certain embodiments. For example, a non-transitory medium, such as a hardware storage device, may be used to store the control logic, which may include executable instructions.

[0198] Certain embodiments may be implemented using programmed general-purpose digital computers, application-specific integrated circuits, programmable logic devices, field-programmable gate arrays, optical systems, chemical systems, biological systems, quantum or nano-engineered systems, etc. Other components and mechanisms can be used. In general, the functionality of certain embodiments can be achieved by any means known in the art. Distributed or networked systems, components and / or circuits can be used. Cloud computing or cloud services can be used. Data can be transmitted or transferred via wires, wirelessly, or other means.

[0199] Furthermore, one or more elements shown in the drawings may be located in a more remote or centralized manner, or may be removed as needed, as long as they are operable. Thus, implementations in which a program or code that enables a computer to perform any of the above methods is stored on a machine-readable medium are also included within the spirit and scope of the present invention.

[0200] A "processor" includes any suitable hardware and / or software system, mechanism, or component that processes data, signals, or other information. A processor may include a general-purpose central processing unit, multiple processing units, a system with dedicated circuitry for implementing a function, or other systems. Processing is not limited to geographic location or time. For example, a processor may perform functions in, for example, "real time," "offline," or "batch mode." Portions of processing may be performed at different times and in different locations by different (or similar) processing systems. Examples of processing systems include servers, clients, end-user devices, routers, switches, networked devices, etc. A computer is any processor in communication with a memory. Memory may be any suitable processor-readable storage medium, such as random access memory (RAM), read-only memory (ROM), a magnetic or optical disk, or other suitable non-transitory medium for storing instructions executed by a processor.

[0201] As used in the description and claims herein, the words "a," "an," and "the" include the plural unless the context clearly dictates otherwise. Also, as used in the description and claims herein, "in" means "in" and "on" unless the context clearly dictates otherwise.

[0202] Thus, although specific embodiments have been described herein, any modifications, variations, and substitutions are encompassed within this disclosure. In some cases, certain embodiments may employ some features without corresponding use of other features without departing from the spirit and scope of the invention. Accordingly, many modifications may be made to adapt a particular situation or material to the essential scope and spirit.

Claims

1. A computer program storing instructions for performing a computer-implemented method, the method comprising: receiving a first uniform resource locator (URL) pattern, the first URL pattern including a portion representing an application and a portion representing a web page within the application, each portion of the application being contained within a container of each container that constitutes a container hierarchy; the method further comprising: associating a state with each said container; creating a state for each portion of the application based on the first URL pattern; receiving a second URL pattern having a different portion than the first URL pattern; and discarding a state of a container associated with the different portion based on the different portion between the first URL pattern and the second URL pattern.

2. 2. The computer program product of claim 1, wherein the method further includes associating a plurality of containers with URL parts of the first URL pattern, the URL parts being separated by slashes, and each of the URL parts of the first URL pattern having a separate container.

3. The computer program product of claim 2 , wherein the method further comprises providing a respective hierarchical path for each container of the plurality of containers and an order of the containers along each hierarchical path.

4. The computer program product of claim 2 , wherein the method further comprises providing specific container access to variables of a specific container and variables of containers along a hierarchical path of the specific container.

5. The method comprises: receiving user input at a design-time tool defining portions of the application; generating computer-executable instructions for the application based on the user input; The computer program product of claim 2 , further comprising executing the generated computer-executable instructions during execution of the application.

6. The method further includes providing a respective life cycle for each of the containers; The computer program of claim 2 , wherein the life cycle includes multiple phases.

7. The computer program product of claim 6 , wherein the method further comprises associating a lifecycle of a container with a URL part corresponding to the container.

8. The computer program product of claim 6 , wherein the phases are mutually exclusive.

9. The computer program product of claim 6 , wherein at least one of the plurality of phases is an event for initiating a chain of actions.

10. The method comprises: creating variables for the plurality of containers based on a hierarchical path of the plurality of containers, the hierarchical path being based on the first URL pattern; The computer program product of claim 2 , wherein the discarding comprises discarding container states associated with the different ones of the plurality of containers based on the hierarchical path.

11. A computer-implemented method, comprising: receiving a first uniform resource locator (URL) pattern, the first URL pattern including a portion representing an application and a portion representing a web page within the application, each portion of the application being contained within a container of each container forming a container hierarchy; the method further comprising: creating a state for each portion of the application based on the first URL pattern; receiving a second URL pattern having a different portion than the first URL pattern; and discarding a state of a container associated with the different portion based on the different portion between the first URL pattern and the second URL pattern.

12. 12. The method of claim 11, further comprising associating a plurality of containers with URL parts of the first URL pattern, the URL parts being separated by slashes, each of the URL parts of the first URL pattern having a separate container.

13. The method of claim 12 , wherein the method further comprises providing a respective hierarchical path for each container of the plurality of containers and an order of the containers along each hierarchical path.

14. The method of claim 12 , further comprising providing specific container access to variables of a specific container and variables of containers along a hierarchical path of the specific container.

15. The method comprises: receiving user input at a design-time tool defining portions of the application; generating computer-executable instructions for the application based on the user input; The method of claim 12 , further comprising executing the generated computer-executable instructions during execution of the application.

16. The method of claim 12 , wherein the method further comprises providing each container of the plurality of containers with a respective life cycle, the life cycle including a plurality of phases, the plurality of phases being mutually exclusive.

17. The method of claim 16 , further comprising associating a container lifecycle with URL parts corresponding to the plurality of containers.

18. The method of claim 16 , wherein at least one of the plurality of phases is an event for initiating a chain of actions.

19. The method comprises: creating variables for the plurality of containers based on a hierarchical path of the plurality of containers, the hierarchical path being based on the first URL pattern; The method of claim 12 , wherein the discarding comprises discarding container state associated with the different ones of the plurality of containers based on the hierarchical path.

20. 1. A system comprising: one or more processors; A non-transitory processor-readable storage device storing the computer program of any one of claims 1 to 10.

Images