Creating dynamic data bound container hosting views and editable forms

Abstract

A method (400) for using a user-fillable form (202) in a host container (120) includes receiving, at the host container, a user-fillable form bound to dynamic data (206) from an underlying data source (210), where the user-fillable form has a data structure (222) generated by pre-fill coding. The method further includes converting the user-fillable form into a hosting format of the host container (232). The method also includes rendering the user-fillable form in a user interface (122) using a hostable format of the host container. The method further includes receiving, at a user interface of the host container, a data entry from a user (10) of the host container for input to the user-fillable form, and updating, by the host container, the dynamic data from the underlying data source by persisting data (12) from the data entry in a data store (210) associated with the underlying data source.

Description

This application is a divisional application of the following application: International application number of the original application: PCT / US2022 / 073909 International filing date of the original application: July 19, 2022 National application number of the original application: 202280068993.9 Title of the original application: Creating a dynamic data binding container hosting views and editable forms Technical Field

[0001] The present disclosure relates to creating dynamic data-binding containers hosting views and editable forms. Background Art

[0002] An application designer or design team typically spends hours, days, or weeks perfecting the design of the front-end functionality of a particular application. The designer then hands the design of the front-end functionality to a developer or computer software engineer, who again spends hours, days, or weeks writing computer code to recreate these designed features. This designer / developer paradigm common in the application industry is extremely inefficient, requiring developers to reinvent the wheel for each new feature. In addition, for the same or similar functions, the computer code required to render each front-end function or component (e.g., login function, registration function, user profile function, content or news feed, navigation bar, media upload function, map and location function, and other common functions) is basically the same in different applications. However, developers / computer software engineers usually need to develop these functions from scratch each time, a process that can take days or weeks. Summary of the invention

[0003] One aspect of the present disclosure provides a computer-implemented method for using a user-fillable form in a host container. When executed by data processing hardware, the computer-implemented method causes the data processing hardware to operate. The operation includes receiving a user-fillable form bound to dynamic data from an underlying data source at a host container, wherein the user-fillable form has a data structure generated by pre-filled encoding. The operation further includes converting the user-fillable form into a hostable format of the host container. The operation also includes rendering the user-fillable form in a user interface using the hostable format of the host container. The operation further includes receiving, at the user interface of the host container, data entries for input into the user-fillable form from a user of the host container, and updating, by the host container, the dynamic data from the underlying data source by persistently storing the data from the data entries in a data store associated with the underlying data source.

[0004] Another aspect of the present disclosure provides a system for using a user-fillable form in a host container. The system includes data processing hardware and memory hardware that communicates with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to operate. The operation includes receiving a user-fillable form bound to dynamic data from an underlying data source at a host container, wherein the user-fillable form has a data structure generated by pre-filled encoding. The operation further includes converting the user-fillable form into a hostable format of the host container. The operation also includes rendering the user-fillable form in a user interface using the hostable format of the host container. The operation further includes receiving, at the user interface of the host container, data entries for input into the user-fillable form from a user of the host container, and updating the dynamic data from the underlying data source by the host container by persistently storing the data from the data entry in a data store associated with the underlying data source.

[0005] Implementations of any aspect of the present disclosure may include one or more of the following optional features. In some implementations, the operation further includes requesting, by the host container, an application associated with the data source to generate the user-fillable form, wherein receiving the user-fillable form includes receiving the user-fillable form generated by the application associated with the data source. In some examples, rendering the user-fillable form in the user interface includes rendering the user-fillable form in the user interface in response to an indication of a user action performed in the host container, wherein the user action indicates that the user intends to communicate with the underlying data source. In some configurations, the operation also includes querying the underlying data source for the dynamic data, receiving query results from the underlying data source, the query results including current data corresponding to the dynamic data, and filling in the current data in the user-fillable form, wherein the user-fillable form rendered in the user interface includes the current data. In some examples, the operation further includes determining whether the data entry received from the user for input into the user fillable form includes a valid data entry, wherein when the data entry received from the user for input into the user fillable form includes the valid data entry, updating the dynamic data from the underlying data source by persistently storing the data from the data entry in the data store associated with the underlying data source. In these examples, when the data entry received from the user for input into the user fillable form includes an invalid data entry, the operation may generate an indication that the data entry is invalid and receive a valid form of the data entry. Here, updating the dynamic data from the underlying data source includes updating the dynamic data from the underlying data source using the valid form of the data entry. In some embodiments, the operation also includes determining that the user is an authenticated user who is allowed to access a portion of the dynamic data associated with the data entry. The user fillable form may include a read-only field and an editable field capable of receiving user-generated data. The underlying data source may be hosted by an application residing outside the host container. The dynamic data from the underlying data source may be updated when the user interface receives the data entry from the user for input into the user fillable form.

[0006] In some examples of any aspect of the present disclosure, the host container executes an email communication application. In these examples, the user interface that renders the user fillable form can include the body of an email message. In some implementations, the dynamic data from the underlying data source is updated in response to a trigger associated with the data entry entered into the user fillable form rendered in the body of the email message.

[0007] The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A is a schematic diagram of an example computing environment that includes a forms manager.

[0009] Figure 1B is a schematic diagram of an example computing environment including a form manager that coordinates use of forms by multiple parties.

[0010] Figures 2A to 2E is a diagram of the form manager example.

[0011] Figure 3A and 3B is a diagram of a sample form generated by the Form Manager.

[0012] Figure 4 is a flow diagram of an example operational arrangement of a method for using an editable form with a host container.

[0013] Figure 5 is a schematic diagram of an example computing device that may be used to implement the systems and methods described herein.

[0014] The same reference symbols in different drawings denote the same elements. DETAILED DESCRIPTION

[0015] Today, many people's workloads revolve around various computing applications. That is, in the digital age, people's work and lifestyles tend to be centered around computers. For example, many people's work relies on email communication, word processing applications, spreadsheet applications, file generation and modification applications, database or data collection applications, etc.

[0016] Due to the plethora of different applications, people have become accustomed to using multiple applications at the same time or using multiple pages of a single application as part of their daily workspace (e.g., multiple tabs in a web browser). Whether the user is aware of this or not, the user often transfers data from one application or page to feed or input into another application. For example, a user generates slides for a presentation by taking data from a spreadsheet to build a chart or convey a specific message. This type of multitasking is often called context switching (or task switching). In other words, the user switches his or her attention between two or more tasks (e.g., two or more content delivery objects). Unfortunately, from a human perspective, switching one's attention between multiple tasks is not only taxing on the human brain, but also inefficient and may reduce potential productivity. Here, each change of attention inherently results in transition times that may accumulate into a significant amount of time loss. For example, a simple task of copying data from one application (e.g., a pdf form reader) to another application (e.g., a spreadsheet or database) may become very cumbersome and time-consuming. In addition, every time the task changes, the human mental facility must adjust itself. This can require high sustained attention to multitask for longer periods of time; increasing the likelihood of mental fatigue. When one or more of these factors compound, context switching can lead to unwanted outcomes, such as errors or overall reduced productivity.

[0017] For example, in the case where an employee wants to request a vacation, the employee's company may have a template form that requests specific information from the employee regarding the vacation request. For example, the form may include fields that prompt information such as the vacation date, the employee's department, the employee's manager, the manager's email, the employee's email, whether the employee is using vacation time or sick time, etc. Here, the employee's company may have a policy to complete a vacation request form and submit it to the employee's manager. In this case, the completed form must be emailed to the employee's manager as an attachment. After completing the form, the employee sends an email to his or her manager with a summary of the request in the body of the email and the completed form as an attachment. In this case, the employee may use multiple applications to complete this seemingly simple request. The employee must use an email application to generate the email, a document retrieval application to retrieve the form, and a form filling application to complete the form (or use some means to print a hard copy and then re-digitize the completed hard copy). This means that the employee's workflow may be to create an email to his or her manager, then use the document retrieval and form filling applications to complete the form, and then return the email to attach the completed form and summarize the request in the body of the message to the manager. This process inherently places a burden on employees to switch tasks (e.g., from filling out a form to generating an email). Additionally, if employees are not careful, there may be discrepancies between the completed form and the summary in the email, which can add further burden to the process (e.g., additional follow-up).

[0018] Situations like requesting time off are common in the work environment, even though these processes are not usually substantive processes related to the employee's job function. That is, in addition to their primary job function, employees often need to conduct auxiliary processes (e.g., administrative processes) such as time off requests, reimbursement requests, travel requests, meeting requests, approval requests, signature requests, quality control documentation, process deviation requests, overtime requests, etc. Here, it would be advantageous if these auxiliary processes were more efficient and not frequently affected by context switching, so that employees can focus their time on other job functions (e.g., primary job functions).

[0019] Context switching also tends to be present today due to the data-driven nature of many workflows. With the increase in computing power and accessibility, a large amount of data is being collected and made available for various analyses. However, analysis of this collected data often requires the data to be transferred or converted into one or more forms. Returning to the vacation request example, the employee's manager receives a completed vacation request form and may be asked to enter the information into some log of the employee's vacation (e.g., for payroll and accounting purposes). Here, this means that the manager opens the completed form in a document reader application and transfers the information collected in the completed form into an employee database (e.g., a spreadsheet containing employee information). Optionally, the manager may need to cross-reference the employee database to determine whether the employee is eligible to request vacation, or optionally, whether the employee's request is feasible in the employee's schedule. For example, an employee may be one of two people who can perform a certain manufacturing process. Here, another employee who can perform the manufacturing process may have been granted vacation on the requested date. In the case of such a scheduling conflict, the manager may deny the employee's request or notify the employee of the conflict. Much like the task of generating a vacation request by an employee, the management side of the vacation request / approval process may also require context switching to enter data into an employee database and respond to the employee request (eg, via a reply email).

[0020] To address some of the issues associated with context switching, some applications have evolved to serve as centralized workspaces or hubs. In other words, these centralized applications can be integrated with one or more other applications in some way. Some centralized applications can improve efficiency by linking or assigning users to another application with minimal additional user input. For example, an email communication application opens a calendar or scheduling application when a meeting request is generated. In another example, a file management application renders a static view or preview of a file for the user. Although this integration can improve efficiency by directing users directly to a specific destination, this approach still inevitably encounters context switching because users are transferred from their current location. In other words, the user does not stay in the page of the main application. Instead, the main application is configured to transfer the user to another window or page. In the case of scheduling a meeting request in an email application, the email application opens a window to the schedule of the invited guests, and then the user returns to the email to complete and send the meeting request. Similarly, when an email includes an attached document, the document is not embedded in the body of the email in real time, so that the document can be edited in the email body itself. Instead, the email application provides access to the document through a viewer application that coordinates with the email application.

[0021] To overcome some of these problems, the methods described herein are used to generate forms that can be rendered within a page of a main application. In addition, these forms may include editable portions within the page that collect data from the user. These forms can also be configured so that when a user submits a form with input data (e.g., within a page) or simply enters data into a form, the data is updated in an underlying data source (e.g., a data store associated with the underlying data source). This means that in the case of a vacation request / approval, an employee can open an email template that loads a vacation request in the body of the email. The employee can then fill in the information in the necessary fields of the email body to complete the vacation form. After the employee's vacation request data is entered into the form rendered in the body of the email, the form may operate in several ways. In one approach, the form is configured so that when the employee enters data into the form, the data is automatically updated in an underlying database or data store that includes the employee's vacation request information. In other approaches, the form is configured so that when the employee sends an email including the completed form to his or her manager, the action of sending the email triggers the data entered into the form to be updated (e.g., persistent storage) in an underlying database or data store that includes the employee's vacation request information. In yet another approach, the form is configured with a submit button separate from the send function, and when the employee selects the submit button, the submit action triggers the data entered into the form to be updated in an underlying database or data store (eg, persistent storage) including the employee's vacation request information.

[0022] Additionally or alternatively, in-page forms rendered in the application may include live or current data from the underlying source. That is, in the case of the scheduling conflict mentioned earlier, the manager may not have yet entered the approved time off for other employees into the employee database. In a traditional scenario, where an employee might be able to see a portion of the employee database to identify the scheduling conflict at the time of the request, the manager's inability to enter other employees' requests would result in the employee generating requests for conflicting dates without knowing it. In contrast, if the employee database is automatically updated as other employees submit requests, the employee may be able to view a live version of the employee database for scheduling purposes and avoid spending time generating requests that may be rejected.

[0023] Unfortunately, rendering editable forms in an application is not without its difficulties. Namely, generating a form that is compatible with a specific part of an application (e.g., within a page) often becomes a time-consuming coding process. In other words, a senior coder or programmer needs to author the form in a way that is compatible with the target application (or a portion of it). However, this may be cost or time prohibitive, especially for secondary processes. In other words, generating custom programmatic forms to conduct secondary processes may not be consistent with other business interests, such as investing time and resources to improve the primary process.

[0024] To avoid custom programming, the forms described here are the result of a codeless form generator. A codeless form generator refers to an engine or form creation application that includes templated coding or pre-filled coding of form elements, form dependencies, and / or form automation. Through templated coding or pre-filled coding of these or other form components, entities without complex coding can use a codeless form generator to build customized forms for specific target applications. In other words, entities using a codeless generator will not need to specify or enter code to build a form. This enables users with a wide range of coding skills (e.g., from little to no coding skills to more sophisticated coders) to generate user-fillable forms that can be operated within a page or embedded in a specific part of a target application. In addition, a form may exist or be configured to be embedded in an application that is hosted (e.g., executed) in a host container that does not include the underlying data source of the form. In this regard, the underlying data source of the form can be hosted on or associated with another application outside the host container, where the form will be rendered for the user to use.

[0025] refer to Figure 1A and 1B , the computing environment 100 includes a user 10 operating a user device 110 (also referred to as device 110) to communicate with a form manager 200. The form manager 200 is configured to generate a form 202 (also referred to as a user fillable form 202) that can be hosted in a format that a host container 120 can render as a user interface 122 for the user 10. The host container 120 generally refers to an abstraction at the application layer that can virtualize an operating system to run an application (e.g., application 124) as an independent and self-contained application environment. In this sense, the host container 120 acts as an independent unit with all necessary components (e.g., application binaries, application dependencies, hardware requirements, etc.) to operate the application 124 contained therein.

[0026] like Figure 1AAs shown, when the application 124 is executed, the application 124 can generate a user interface 122 that presents a form 202 from the form manager 200 to the user 10. Here, the application 124 is considered a front-end application because it is a user-facing application that allows the user 10 to enter user data 12 into the form 202. For example, the form 202 includes form elements 204, 204an, such as form fields 1-n from which the user 10 can read data (e.g., read-only elements) or write data to (e.g., write user data 12 to editable elements). Once the form 202 receives the user data 12 (e.g., as form data entries), the form manager 200 transmits the user data 12 to an underlying data source 210 or form data source 210. The form data source 210 is configured to store the user data 12 and other form data 206 related to the form 202. Here, the form data source 210 is shown as a data store integrated with the form manager 200. In other configurations, however, form data source 210 is merely associated with or accessible to form manager 200 (eg, another database or database management application in communication with form manager 200).

[0027] Device 110 may correspond to any computing device associated with user 10 and / or author 20. When device 110 is associated with user 10, the device is capable of executing host container 120 and / or application 124. For example, Figure 1A A first user device 110, 110a is depicted as being associated with a user 10 executing an application 124. When the device 110 is associated with the author 20, the device 110 can provide processing resources to coordinate form generation (e.g., the form manager 200). For example, Figure 1A A second user device 110, 110b is shown associated with an author 20 using a form manager 200 to generate a form 202 for an application 124. In some examples, the user device 110 includes, but is not limited to, a mobile device (e.g., a mobile phone, a tablet, a laptop, an e-book reader, etc.), a computer, a wearable device (e.g., a smart watch), a smart appliance (e.g., a smart TV), and an Internet of Things (IoT) device, a remote control, a smart speaker, etc. The device 110 includes data processing hardware 112 and memory hardware 114 that communicates with the data processing hardware 112 and stores instructions that, when executed by the data processing hardware 112, cause the data processing hardware 112 to perform one or more operations related to form entry and / or form generation.

[0028] The device 110 may also include a display 116 to display graphical user interface (GUI) elements (e.g., form elements 204) and / or graphical content. Some examples of GUI elements include windows, screens, icons, menus, fields, text, etc. In this sense, the display 116 is configured to display the user interface 122 including any form elements 204 associated with the form 202 to the user 10. These form elements 204 may be elements that the user 10 can interact with (e.g., selectable GUI elements or editable GUI elements) in order to enter user data 12 into the form 202.

[0029] The author 20 is an entity that uses the form manager 200 to generate a form 202 that is presented as a user interface 122 in the front-end application 124. Because the form manager 200 includes a code-free form generator (e.g., a form builder 220), the author 20 of the form 202 does not need to be an experienced programmer or coder to design and implement the form 202 of the host container 120. Instead, the author 20 can be an administrative entity, an information technology person, or some other entity responsible for the process executed at the application 124 integrated with the form 202 (e.g., an approval manager for a vacation request / approval process). The author 20 can be the same entity as the user 10 or a different entity. For example, the author 20 refers to the user of the form 202, but in the form generation stage rather than the form input stage. In other words, the user 10 designs the form 202 as the author 20 and then acts as the user 10 during the implementation of the form 202.

[0030] like Figure 1A As shown, the host container 120 and / or the form manager 200 may be software hosted by a remote system 130 (e.g., a distributed computing system (e.g., a cloud environment)) that communicates with the user device 110 via a network 140. For example, the application 124 or the form manager 200 may be provided to the user 10 and the author 20 as software as a service (SaaS) from a software service provider (e.g., an owner / manager of the remote system 130). The remote system 130 may include scalable remote resources 132, such as remote data processing hardware 134 (e.g., a remote server or CPU), remote memory hardware 136 (e.g., a remote database or other storage hardware), and / or remote software 138 (e.g., a software application hosted by the remote system 130). The device 110 may utilize the remote resources 132 to perform various functions related to form input and / or form generation.

[0031] In some implementations, one or more components of the form manager 200 may reside on the device 110 (referred to as on-device components) or remotely (e.g., reside on a remote system 130), but communicate with the device 110. In other words, any of these components of the form manager 200 (e.g., data store 210, form builder 220, form converter 230, and updater 240) may be local or remote in any combination. For example, the form converter 230 may reside on the device 110 to convert the form 202 into a format that the host container 120 (e.g., application 124) can render, while other components (e.g., data store 210, form builder 220, and updater 240) reside remotely. In some configurations, when a component of the form manager 200 is substantial in size or processing requirements, the component may reside in the remote system 130. However, when device 110 can support the size or processing requirements of one or more components of form manager 200, one or more components of form manager 200 may reside on device 110 using data processing hardware 112 and / or memory hardware 114. For example, form manager 200 may be an application downloaded by user 10 and stored in memory hardware 114 of user device 110. Alternatively, one or more components of form manager 200 may reside locally / on the device as well as remotely. For example, when a connection to network 140 is available between device 110 and remote system 130, one or more components of form manager 200 may execute by default on remote system 130, but when the connection is lost or network 140 is unavailable, components of form manager 200 are instead executed locally on device 110.

[0032] The form 202 authored by the author 20 and generated by the form manager 200 is generally referred to as a user-fillable form. That is, the form 202 includes one or more fields or form elements 204 to which the user 10 can write user data 12 (e.g., editable fields) or read data from (e.g., read-only fields). The author 20 can generate the form 202 so that the form 202 can support form elements 204 from traditional form fields (e.g., text areas, drop-down lists, and / or user action buttons) or even non-traditional form fields. The form 202 can also include varying degrees of logic so that the user 10's data entry or user action within the form 202 can trigger different events to occur (i.e., perform some pre-configured automation). For example, in the case of a vacation request, the form 202 is configured to automatically send the completed form 202 to the employee's manager when the user 10 completes a specific set of fields or the user 10 selects "Submit". For example, the author 20 configures the form 202 to find the manager corresponding to the requesting employee and populate the manager's email as the destination of the completed form 202 or some portion thereof. This means that user input and / or user actions in form 202 can be published or transmitted to a listener endpoint; thus allowing these inputs / actions to be combined with other functions, such as persisting the input user data 12 to the underlying data source 210 or transmitting the input user data 12 to a specific destination (e.g., a manager's email address).

[0033] Generally speaking, the author 20 designs the form 202 to be associated or bound to a specific set of data, referred to as form data 206. Here, the author 20 can design the form data 206 as any type of schema or view definition. When the form 202 is subsequently rendered as the user interface 122 at the application 124, the form 202 is configured to render the form data 206 that has been bound to the form 202 by the author 20. For example, when the user 10 launches the form 202 at the application 124, the form 202 queries (e.g., via the form manager 200) the underlying data source 210 for the form data 206, and generates the form 202 for the user 10 using the queried form data 206. For illustration, Figure 1AAn application 124 and / or user device 110 is depicted, which generates a form generation request 14 that queries the form manager 200 for form data 206. In some examples, the author 20 configures the form data 206 as data from a table or data set with a defined schema / defined type. In other words, the author 20 binds the form data 206 to a specific data model (e.g., a custom data model or a preconfigured data model). For example, in a vacation approval process, the form 202 for an employee (i.e., user 10) can be bound to data from a table in an employee database. Here, although the table can be modeled to include many different data columns related to the employee, the author 20 can design the form 202 to be bound to a specific data column so that the data entered into the form 202 enters the data (e.g., as a new record or data entry) into a specific column of the table. That is, depending on the design of the underlying data source 210 and the form 202, the form data 206 can correspond to a subset of the columns in the row of a specific reference table.

[0034] Although form 202 may be bound to form data 206, the fact that form 202 is bound to form data 206 does not make form data 206 static in nature. Rather, form data 206 may change dynamically (e.g., within a particular set of constraints). For example, form data 206 may be bound to columns of an employee database that include "employee name," "employee email," "employee manager," "manager email," "request date," and a column indicating whether the request is for paid vacation or sick leave. In this example, when form 202 is rendered, some of these fields of form data 206 may be pre-populated with data (e.g., readable fields), while other fields may be blank to allow user 10 to enter user data 12 into the fields (i.e., writable fields). That is, "employee manager" and "manager email" may be populated in form 202, but the field corresponding to "request date" may not be populated (i.e., a blank field prompting for the requested vacation date). In this example, if the organization undergoes a reorganization, the employee's manager may change in the underlying data source 210, but the form 202 will still be populated with the new approving manager (e.g., without necessarily requiring any further user input). In this regard, the form 202 can be bound to the fluid and changing form data 206 so that the form 202 represents the live (i.e., current) form data 206.

[0035] In addition, the form 202 may extract form data 206 from the underlying data source 210 (e.g., a table associated with the source 210) to facilitate data constraints on the user data 12 that may be entered into the form 202. In other words, if the author 20 authored the form 202 to include five columns in a table, one of which is constrained to be a price or numeric data type, the form 202 will reflect the data type constraint on the user interface 122. For example, if the user 10 attempts to enter user data 12 that does not satisfy the constraints, the form 202 may not accept the user data 12 or allow the user data 12 to submit the form 202 without satisfying the constraints. For example, the form 202 is configured to convey an indication of whether the user data entry is a valid data entry (i.e., satisfies any constraints) or an invalid data entry. In addition, when the user 10's data entry is an invalid data entry, the form 202 may be configured by the author 20 to provide some indication of why the data entry is invalid (e.g., "Invalid data type - please enter a number"). In this regard, the form 202 may be configured by the author 20 to have a validation capability to ensure that the user data 12 satisfies the required constraints. By satisfying such constraints, the user data 12 can then be input into the underlying data source 210 (eg, a table) without disrupting or disturbing the organization of the data source 210 .

[0036] Further references Figure 1A , when using application 124 from host container 120, user device 110 (e.g., via user 10) may perform some action that invokes the use of form 202. For example, application 124 is an email communication application, and user 10 creates a new email that populates form 202 as a template embedded in the body of the email. Here, for the email communication application, form manager 200 may set form 202 to render in a specific format that is compatible with the body of the email, such as Accelerated Mobile Pages (AMP). AMP refers to a specific language format similar to Hypertext Markup Language (HTML) web pages, but differs in that AMP is configured with a limited set of allowed functionality (e.g., allowing it to be integrated with email) to facilitate mobile deployment. When an action occurs (e.g., when user 10 creates an email that will populate form 202), form 202 may be configured to request form data 206 corresponding to form 202 upon startup. For example, Figure 1AThe user device 110 and / or application 124 is depicted transmitting a form generation request 14 to the form manager 200. In response to the request 14, the form manager 200 may return a form 202 along with form data 206 to the source of the request 14. Using the form 202 and its corresponding form data 206, the user 10 is able to enter user data 12 into the form 202 (e.g., enter the user data 12 into one or more field elements 204). In the case where the form 202 is embedded in the body of an email, sending the email including the form 202 may serve as a trigger to transmit the user data 12 in the form 202 back to the form manager 200. Using the user data 12, the form manager 200 may update the form data 206 in the underlying data source 210 by persisting the user data 12 to the form data source 210 (e.g., storing the user data 12 in a data store associated with the data).

[0037] Figure 1B Similar to Figure 1A , but one or more forms 202 are shown for use in a multi-party scenario. A multi-party form scenario may be a situation where a first process (e.g., filling out a first form 202, 202a) may trigger one or more secondary processes. Returning to the vacation request / approval example to describe Figure 1B , the first process refers to the employee as a first user 10, 10a who fills out a vacation request form 202, 202a. The first process then triggers a secondary process for the employee's manager to approve the vacation, as shown by the second user 10, 10b. Here, in a first step 1, the user device 110 generates a request 14 for a form 202 and / or form data 206 corresponding to the form 202. In step 2, the form manager 200 returns the form 202 along with the form data 206 and coordinates with the application 124 to render the form 202 as a user interface 122 at the application 124. In some examples, when the form manager 200 renders the form 202, the form manager 200 is configured to generate a new record in the form data source 210 for the new or requested instance of the form 202 (i.e., the form manager 200 inserts a new row in the table corresponding to the form data 206). In other words, the form manager 200 renders the form 202 with the form data 206 including one or more empty entries (ie, blanks) so that the user 10 can submit the user data 12 into these empty entries. Figure 1BIn the example of , the form 202 includes three field elements 204, 204ac. The first element 204a is a drop-down list that characterizes the type of request made by the request form 202a (for example, the user 10 can select the "vacation" request type). The second element 204b is a field for the user 10 to enter the user data 12 corresponding to the requested vacation data (for example, displayed as "August 16-20"). The third element 204c is an action element that triggers the submission of the request form 202a. Here, the user 10 completes the request form 202a and selects the submit button (i.e., the third element 204b). By selecting the "Submit" button, the "Submit" button will serve as a trigger for the vacation approval secondary process. That is, the submit button can be configured to generate a subsequent approval form 202 (for example, shown as the second form 202, 202b) after submitting the request form 202a (for example, shown as the first form 202, 202a). Additionally, at step 3, the first user 10a submits the request form 202a to send the user data 12 entered into the request form 202a to the form manager 200 so that the form manager 202 can persist the user data 12 into the data form source 210 (e.g., shown as a table). Step 4 can occur simultaneously with step 3 or after step 3. At step 4, the manager 10b receives an approval form 202b including four form elements 204d-g, three of which are populated with the user data 12 from the employee 10a. In this case, the form 202 has a blank fourth element 204g so that the manager 10b can select from a drop-down list, for example, whether the manager 10b approves or denies (or some alternative response) the vacation request from the employee 10a. In this example of the approval form 202b, the other elements 204d-e identify the type of request (e.g., shown as a vacation request), the employee submitting the request (e.g., employee X), and the requested vacation dates (e.g., shown as "August 16-20"). Although not shown, similar to step 3, when the manager 10b completes the fourth element 204g, the manager 10b can transmit the user data 12 (e.g., approval or rejection) entered by the manager 10b back to the form manager 200. In this regard, any additional data generated by the manager (such as the manager's approval decision) is stored in the form data source 210.

[0038] refer to Figure 2A-2E, the form manager 200 includes a form data source 210, an application editor 225, and a runtime server 235. The application editor 225 implements a form builder 220, and the runtime server 235 implements a form converter 230 and an updater 240. In some embodiments, the form manager 200 acts as a backend application for the author 20 and the host container 120 or application 124, rather than communicating directly with the user 10. The form builder 220 acts as a codeless form generator. That is, the author 20 uses the form builder 220 to build a form 202 that will be rendered to the user 10 as a user interface 122 (e.g., of the application 124 of the host container 120). In this sense, the form builder 220 specifies the user experience (i.e., how the form 202 looks and feels). Using the form builder 220, the author 20 can specify the form data 206 from the form data source 210. For example, the author 20 specifies that the form data 206 corresponds to a portion of one or more data tables stored at the form data source 210. In addition to simply specifying form data 206, the author 20 uses the form builder 220 to generate the data structure 222 of the form 202 according to the templated or pre-coded form elements 206. In other words, the form builder 220 can bind the form data 206 to form widgets, such as drop-down lists, lists, buttons, icons, fields, text, prompts, large titles (titles), small titles (headings), or different types of graphical content (e.g., charts, diagrams, graphics or other media content). Using pre-coded or templated elements 204, the author 20 does not need to enter or specify any specific coding of the form 202, but can focus on various aspects of the form 202, such as the aesthetics or logic of the form. In this sense, the author 20 does not need to be a developer who often needs to know coding and design, but can handle the design of the form 202 and how it will work in a specific workflow. This allows the author 20 to focus on how the form 202 will be seamlessly integrated with the application 124 to prevent undesirable user actions, such as context switching. The author 20 may also specify a message or text (eg, an email body as a preamble or footer) to accompany the form 202 when the form 202 is generated. Thus, other user-specified content may accompany the form data 206 in the generated structure 222 of the form 202.

[0039] The application editor 225 implements the functionality of the form builder 220. In response to the author 20 selecting form widgets and other aspects of the form, such as form elements 204 for data entry or data display and email recipients for a given form 202, the application editor 225 links the underlying form data 206 to the selected form elements 204 and generates a data structure 222. When appropriate, the application editor 225 can also provide activation for subsequent processes triggered by actions or data entries on the created form 202. For example, in the vacation request example, the application editor 225 can link the data provided in the request form with the defined columns of the form data 206 and link the submission of the request form 202a with the generation of the approval form 202b. Such links can be defined by the author 20 of the form through pre-coded form elements 204 in the form builder 220 and enabled by the application editor 225. Therefore, the structure 222 includes the pre-coded elements 204 selected by the author provided by the form builder 220 and the underlying links between the elements 204 and the data source 210 provided by the application editor 225.

[0040] The form builder 220 then communicates the structure 222 of the form 202 to the form converter 230. The form converter 230 converts the form 202 into a hostable format 232 for the host container 120. For example, in the case of an email application, the form converter 230 converts the form 202 into an AMP format 232 that can be rendered in the email itself (e.g., the body of the email). When the form converter 230 converts the form into the hostable format 232, the form converter 230 is then configured to render the form 202 in the user interface 122 using the hostable format 232. In some examples, when the user 10 or the user device 110 requests that the form 202 be loaded into the host container 120 as the user interface 122, the form converter 230 renders the form 202 in the user interface 122. For example, the user 10 performs an action that triggers the form converter 230 to render the form 202 in the hostable format 232 at the application 124. Optionally, when the host container 120 receives the communication from the form converter 230, the host container 120 can detect that it has received a form 202 in a hostable format 232 suitable for the application 124 of the host container 120, and render the form 202 accordingly. In this sense, the form converter 230 can operate in conjunction with the application 124 and / or the host container 120 to understand how the form 202 should be converted to the hostable format 232 in order to be appropriately rendered as the user interface 122 in the host container 120.

[0041] By using the form builder 220, the author 20 can define how the form 202 will be rendered to the user interface 122. In other words, the author 20 can make choices when creating the form 202 using the form builder 220, which will determine the view of the form 202 and how the form will act and behave on the user interface 122. Similar to other choices made by the author 20, defining the view and behavior of a given form 202 can be provided as pre-coded form elements 204 enabled by the application editor 225 and defined within the structure 222.

[0042] Thus, the form converter 230 receives the structure 222 of the form 202 from the form builder 220 and renders the form 202 as the user interface 122 via the application 124 of the host container 120. As described above, the application 124 of the host container 120 may require a hostable format 232 (e.g., an AMP format) to properly display the form 202 as the user interface 122. The form converter 230 maps or links the form data 206 to the appropriate fields on the user interface 122 so that the structure 222 that the author 20 has defined can be converted to the hostable format 232. For example, in the example of a form embedded in the body of an email, the form converter 230 can convert the structure 222 to link the defined columns of the form data 206 with specific fields of the form embedded in the email so that the user input received in the field or the information displayed to the user in the field can correspond to the defined form data 206. Thus, the form converter 230 automatically converts the structure 222 into the appropriate hostable format 232 and maps the form data 206 to the fields at the user interface 122 before the host container 120 receives the form 202.

[0043] The form converter 230 may also be configured to render the form 202 in the user interface 122 with the latest form data 206. To render the live or current form data 206, 206C, the form converter 230 may transmit a query 234 for the current form data 206, 206C to the form data source 210 when rendering the form 202. In response to the query 234, the form converter 230 receives query results corresponding to the current form data 206C stored at the form data source 210. Using the current form data 206C, the form converter 230 renders the form 202 so that the form 202 is populated with the latest form data 206C.

[0044] With the form 202 rendered as the user interface 122, the user 10 can then continue to use the device 110 to input the user data 12 into the form 202. When the user 10 enters the user data 12 as a data entry into the form 202, the updater 240 is configured to obtain the user data 12 entered into the form 202 and update the form data 206 from the form data source 210. For example, the updater 240 updates the form data source 210 with the user data 12 by persistently storing the user data 12 from the data entry into the form 202 in the data store associated with the form data source 210. The updater 240 can perform its update function according to the command, or listen to a trigger event to start its data update process. For example, the form 202 includes a submit button, and when the user 10 selects the button, the updater 240 updates the form data 206 from the form data source 210 with the user data 12. In other instances, the form 202 may be configured so that a specific action by the user 10 (e.g., a specific data entry, set of data entries, or some other user input) initiates the updater 240 to perform its data update process. That is, the form builder 220 may have bound an event to a specific portion of the form 202 so that when the event occurs, the user data 12 collected by the form 202 is sent to the updater 240 to update the form data 206 from the form data source 210. In other words, the updater 240 may transfer the user data 12 to the form data source 210 at any suitable interval, such as in real time (i.e., simultaneously with the user 10's data entry), field by field (i.e., after a single field is populated with the user data 12), or in its entirety after the user data in each field of the form 202 is completed and submitted. The interval at which the updater 240 transfers the user data 12 may be specific to a given form 202 or a specific field or set of fields of the form 202. The author 20 may determine at which interval the updater 240 performs its update function.

[0045] In some examples, the runtime server 235 implements the functionality of the form converter 230 and the updater 240. The runtime server 235 may host conversion logic (i.e., the form converter 230) that is capable of converting the structure 222 into a hostable format 232 so that the application 124 of the host container 120 can display the user interface 122 as intended by the author 20. The runtime server 235 may also host appropriate structures for querying the current form data 206, 206C and transmitting the form data 206C to the application 124. In other words, the runtime server 235 may provide an application programming interface (API) endpoint for transmitting the hostable format 232 and the form data 206, 206C to the application 124 of the host container 120. Likewise, the runtime server 235, via the updater 240, may enable a conversion of the user data 12 entered by the user 10 at the form 202 to be stored as the form data 206 in the form data source 210. Thus, the runtime server 235 can provide an API that transmits the form 202 and form data 206 in the hostable format 232 to the application 124, and the API can receive the user data 12 and transmit it to the form data source 210. Thus, the form data source 210 can be hosted away from the application 124 of the host container 120, and the runtime server 235 can act as a proxy for the application 124 to read and write to the data source 210.

[0046] In some examples, when the updater 240 receives the user data 12 or when the user 10 attempts to enter the user data into the form 202, the updater 240 can provide authentication or verification services for the form manager 200. For example, when the user 10 is entering the user data 12 as a data entry into the form 202, the updater 240 determines whether the data entry is a valid data entry or an invalid data entry. As previously described, the portion of the form 202 that receives the user data 12 may have constraints that only allow specific types of data or specific data formats. In this regard, if the user 10 attempts to enter user data 12 that does not satisfy one or more constraints, the updater 240 may treat the data entry as an invalid data entry. In some examples, when the data entry is invalid, the updater 240 does not use the user data 12 to update the form data 206 of the form data store 210. Additionally or alternatively, the updater 240 or the built-in logic of the form itself can provide an indication to the user 10 that the data entry is an invalid data entry. In addition, the indication can indicate to the user 10 how to reconcile the invalid data entry. For example, user 10 enters text into a field that includes a numeric data type constraint, and form 202 generates a message or other indication that the field is constrained to a numeric data type.

[0047] In some configurations, one or more data entry fields in the form 202 may require authentication. That is, the form 202 may be configured so that certain fields can only be edited by specific users 10 with permission to edit these fields. In other words, the form element 204 may be bound to access rights that may specify which users can read and / or write to a given field. For example, in the case of a vacation request / approval process, the form 202 may include a field for the requester and a field for the manager. Here, if the user 10 does not have the necessary manager credentials, the user 10 may not be able to access or write to the fields specified by the manager. In this sense, the form 202 has the ability to determine whether the user 10 is an authenticated user who is allowed to access a portion of the form data 206 associated with the data entry. These fields may be optionally readable and / or writable, so that a user 10 who is not authorized to write in a given field can still view the field, or the user 10 can only read the field if they are also authorized to write in the field. Therefore, depending on the authorization status of the user 10, the form element 204 can be dynamic. The form element 204 may also be dynamic, depending on the form data 206 bound to the form element 204 or provided via the designation of the author 20. In other words, the form element 204 may be a data-bound field (i.e., it displays or is configured to receive and provide form data 206) that is readable or writable by the user 10 based on factors other than the authorization status of the user 10. For example, in the context of a vacation request / approval process, the form element 204 may be a chart or calendar showing various employees' calendars for vacation days requested by the user 10, such that the user 10 may read (but not edit) the calendar in order to determine whether the requested vacation days are likely to be approved or denied before submitting the form 202. The calendar may also be displayed as read-only to the manager who receives the form 202 submitted by the user 10. Thus, the displayed calendar is a data-bound field because it provides form data 206, but is designated by the author 20 as a read-only form element 204.

[0048] Figures 2B to 2E2 are examples of various configurations of the form manager 200. The form manager 200 may include different windows and sub-windows that allow, for example, an author 20 to design a form 202 to meet his or her needs based on a particular host container 120. For example, the form manager 200 includes a menu 250 with menu options 252, 252an that allow the author 20 to configure the form data 206, the user experience, and / or automation associated with the form 202. Here, the menu 250 includes menu items 252a-n that the author 20 may select to configure a portion of the form 202. In these examples, the menu items 252 correspond to information about the form manager (e.g., "Information"), the data source of the form 202 (e.g., "Data"), the design of the user interface (e.g., "UX"), behaviors that may be configured for the form 202 or automation that may be configured (e.g., "Behavior" and "Automation"), security, such as authentication or access rights that may be associated with the form 202 or who may author the form 202 for certain sensitive data (e.g., "Security"), and the like. Each of these menu items 252 , when selected, may further include one or more windows 260 , 260 an corresponding to further configurable functionality of the selected menu item 252 .

[0049] exist Figure 2B and 2C , author 20 selects menu item 252 corresponding to user experience ("UX") to design the look and feel of form 202. Here, author 20 can design one or more views that can be incorporated into form 202 along with other design-based features of a particular view (such as style, formatting, fonts, etc.). When designing a view, author 20 can specify the form data 206 that can be incorporated into the view and the type of view. Author 20 can also design how to label or title the data in the view. In addition, as Figure 2C As shown, the author 20 can design how the form data 206 will be presented in the view. For example, Figure 2C It is shown that the fields associated with the view have been configured as region data, representative data (e.g., who is the sales representative), project data, and unit cost data. Figure 2C As shown, the author 20 can add or remove data fields associated with the view, and otherwise provide any custom data or field ordering that the author 20 desires.

[0050] refer to Figure 2D and 2E, the author 20 selected a menu item 252 corresponding to automation from the menu 250. Here, the automation portion of the form manager 200 enables the author 20 to generate a robot, which defines specific automation functions. The robot can be configured to define when something happens (i.e., an automation event) and what activities occur in response to the automation event. That is, what task or set of tasks should occur in response to an automation event or trigger event built into the form 202. In the automation menu item 252, the author 20 can switch between windows 260, 260an, which include: "Robot", to generate a robot; "Events", to set up events; "Flow", to configure multiple tasks (i.e., a set or series of tasks) for the robot; or "Tasks", to configure a single task. In Figure 2D In the example shown, author 20 is configuring an AMP email bot that generates an email (i.e., a specified process) when a new record is created using form 202 (i.e., a specified event). The rightmost column also depicts the different actions that can be configured to occur for a task or process (e.g., run a task, change data, branch to a condition, wait for a condition, call a process, or return a value of some type). Additionally, as shown by selecting "Run Task," different categories of actions can be more precisely configured with more detailed actions, such as "Send Email" is a "Run Task." Each of these detailed actions can be pre-coded or programmed so that author 20, for example, only needs to assign a task to specific data in order to create an automation within form 202. Figure 2E In , the author 20 is designing a flow (i.e., a set of tasks) to occur for the form 202. When designing a flow, the author 20 may be able to compound tasks to achieve more complex automation. For example, Figure 2E The process shown is designed to interact with two different email recipients of the multi-party form 202. In addition, the process specifies the details about the email being automatically generated, such as the email subject, email body, and how the form 202 is displayed in the email itself.

[0051] Figure 3A and 3B are examples of two different forms 202 that may be generated by an author 20 using a form manager 200 . Figure 3A shows a form 202 in a form view, and Figure 3BA form 202 is depicted in a detailed view. When generating the form 202, the user 10 is able to select between a form view and a detailed view of the form 202. When the user 10 selects the form view, the form manager 200 generates a form that converts all supported columns from the form data source 210 into inputs (e.g., an email for an email application) that are rendered in the host container 120. Furthermore, in addition to the inputs, the form view of the form 202 may also include a "Save" button. Here, when the user 10 selects the Save button, the data entered by the user 10 (i.e., the user data 12) may be updated in the form data source 210 (e.g., updated by the updater 240). For specific reference, Figure 3A , form 202 is a requester form identifying a purchase request. Here, requester form 202 includes four field elements 204a-d, which specify the requester, the request date, the request reason, and an action element (i.e., a submit button). In this example, the submit button functions like a save button, and when the button is selected, the data entered into form 202 is added or updated in form data source 210. Conversely, Figure 3B is corresponding to Figure 3A 2. That is, the approver form 202 includes details of the user data 12 entered into the requester form 202 in addition to other field elements 204. Here, the fields 204 (e.g., requester and request data) are populated from the requester form, while other field elements 204c-h (e.g., rejection reason, approval comments, decision, and action) may be entered by another user (e.g., a manager with approval authority).

[0052] Figure 4 4 is a flow diagram of an example operational arrangement of a method 400 for using a user fillable form 202 in a host container 120. At operation 402, the method 400 receives, at the host container 120, a user fillable form 202 bound to dynamic data 206 from an underlying data source 210, wherein the user fillable form 202 has a data structure 222 generated by pre-fill encoding. At operation 404, the method 400 converts the user fillable form 202 into a hostable format 232 of the host container 120. At operation 406, the method 400 renders the user fillable form 202 in a user interface 122 using the hostable format 232 of the host container 120. At operation 408, the method 400 receives, at the user interface 122 of the host container 120, data entries 12 for input into the user fillable form 202 from a user 10 of the host container 120. At operation 410 , the method 400 updates, by the host container 120 , the dynamic data 206 from the underlying data source 210 by persisting the data 12 from the data entry in a data store associated with the underlying data source 210 .

[0053] Figure 5 is a schematic diagram of an example computing device 500 that can be used to implement the systems and methods described herein. Computing device 500 is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown here, their connections and relationships, and their functions are merely exemplary and are not meant to limit the implementation of the inventions described and / or claimed in this document.

[0054] The computing device 500 includes a processor 510 (e.g., data processing hardware), a memory 520 (e.g., memory hardware), a storage device 530, a high-speed interface / controller 540 connected to the memory 520 and a high-speed expansion port 550, and a low-speed interface / controller 560 connected to a low-speed bus 570 and the storage device 530. Each of the components 510, 520, 530, 540, 550, and 560 are interconnected using various buses and can be mounted on a common motherboard or in other appropriate ways. The processor 510 can process instructions for execution within the computing device 500, including instructions stored in the memory 520 or on the storage device 530, to display graphical information of a graphical user interface (GUI) on an external input / output device (e.g., a display 580 coupled to the high-speed interface 540). In other implementations, multiple processors and / or multiple buses and multiple memories and multiple types of memories can be used as appropriate. Furthermore, multiple computing devices 500 may be connected, with each device providing portions of the necessary operations (eg, as a server bank, a group of blade servers, or a multi-processor system).

[0055] Memory 520 stores information non-temporarily within computing device 500. Memory 520 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. Non-temporary memory 520 may be a physical device used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program state information) for use by computing device 500. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0056] The storage device 530 can provide mass storage for the computing device 500. In some embodiments, the storage device 530 is a computer-readable medium. In various embodiments, the storage device 530 can be a floppy disk device, a hard disk device, an optical disk device or a tape device, a flash memory or other similar solid-state storage device, or an array of devices, including devices in a storage area network or other configuration. In other embodiments, a computer program product is tangibly contained in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as the above-mentioned method. The information carrier is a computer or machine-readable medium, such as a memory 520, a storage device 530, or a memory on a processor 510.

[0057] The high-speed controller 540 manages bandwidth-intensive operations of the computing device 500, while the low-speed controller 560 manages less bandwidth-intensive operations. This division of responsibilities is exemplary only. In some embodiments, the high-speed controller 540 is coupled to the memory 520, the display 580 (e.g., through a graphics processor or accelerator), and to the high-speed expansion port 550, which can accept various expansion cards (not shown). In some embodiments, the low-speed controller 560 is coupled to the storage device 530 and the low-speed expansion port 590. The low-speed expansion port 590, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device, such as a switch or a router, through, for example, a network adapter.

[0058] As shown, computing device 500 can be implemented in a variety of different forms. For example, it can be implemented as a standard server 500a or multiple servers in a group of such servers 500a, a laptop computer 500b, or a part of a rack-mounted server system 500c.

[0059] Various implementations of the systems and techniques described herein can be realized in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, which may be special purpose or general purpose, coupled to receive data and instructions from and send data and instructions to a storage system, at least one input device, and at least one output device.

[0060] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0061] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logic flows can also be performed by dedicated logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application-specific integrated circuits). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for performing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include or be operably coupled to one or more large-capacity storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive data from or transmit data to them, or both. However, a computer does not need to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices, such as EPROMs, EEPROMs, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0062] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), an LCD (liquid crystal display) monitor, or a touch screen) for displaying information to the user, and optionally having a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound input, voice input, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0063] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Therefore, other embodiments are also within the scope of the following claims.

Claims

1. A computer-implemented method, which, when executed by data processing hardware, causes the data processing hardware to perform an operation, characterized in that The operations include: Obtaining a first user-fillable form bound to dynamic data of a data set from an underlying data source, the first user-fillable form having a first data structure generated by first pre-filled code, the first pre-filled code being written by a writer using a code-free environment; sending the first user-fillable form to a first user for display on a first computing device; receiving, from the first user of the first computing device, a first data entry in response to the first user-fillable form; based on receiving the first data entry, sending a second user-fillable form to a second user different from the first user for display on a second computing device, the second user-fillable form including an approval request associated with the first data entry; receiving, from the second user of the second computing device, a second data entry in response to the second user-fillable form, the second data entry approving an approval request of the second user-fillable form; Approving the approval request based on the second data entry, updating the dynamic data of the data set from the underlying data source by persistently storing the data from the first data entry and the second data entry at a data store associated with the underlying data source, wherein persistently storing the data from the first data entry and the second data entry includes adding a row to a table associated with the dynamic data.

2. The method according to claim 1, characterized in that The operations further include requesting an application associated with the underlying data source to generate the first user-fillable form, wherein obtaining the first user-fillable form includes obtaining the first user-fillable form generated by the application associated with the underlying data source.

3. The method according to claim 1, characterized in that: The first computing device includes a host container.

4. The method according to claim 3, characterized in that The operations further include converting the first user-fillable form into a hostable format for the first host container.

5. The method according to claim 4, characterized in that The operations further include receiving an indication of a user action performed in the host container, the user action indicating that the first user intends to communicate with the underlying data source.

6. The method according to claim 1, characterized in that The operations further include: For the dynamic data, query the underlying data source; receiving a query result from the underlying data source, the query result including current data corresponding to the dynamic data; and The first user-fillable form is populated with the current data.

7. The method according to claim 1, characterized in that The operations further include determining that the user is an authenticated user permitted to access a portion of the dynamic data associated with the first data entry.

8. The method according to claim 1, characterized in that The first user-fillable form includes read-only fields and editable fields capable of receiving user-generated data.

9. The method according to claim 1, characterized in that: The underlying data source is hosted by an application residing external to the first computing device.

10. The method according to claim 1, characterized in that In response to the first data entry of the first user-fillable form, the dynamic data of the data set from the underlying data source is updated.

11. A system, characterized in that: include: Data processing hardware; as well as Memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations including: Obtaining a first user-fillable form bound to dynamic data of a data set from an underlying data source, the first user-fillable form having a first data structure generated by first pre-filled code, the first pre-filled code being written by a writer using a code-free environment; sending the first user-fillable form to a first user for display on a first computing device; receiving a first data entry in response to the first user-fillable form from the first user of the first computing device; based on receiving the first data entry, sending a second user-fillable form to a second user different from the first user for display on a second computing device, the second user-fillable form including an approval request associated with the first data entry; Receiving a second data entry in response to a second user-fillable form from the second user of the second computing device, the second data entry approving an approval request of the second user-fillable form; approving the approval request based on the second data entry, updating the dynamic data of the data set from the underlying data source by persistently storing the data from the first data entry and the second data entry at a data store associated with the underlying data source, wherein persistently storing the data from the first data entry and the second data entry includes adding a row to a table associated with the dynamic data.

12. The system according to claim 11, characterized in that The operations further include requesting an application associated with the underlying data source to generate the first user-fillable form, wherein obtaining the first user-fillable form includes obtaining the first user-fillable form generated by the application associated with the underlying data source.

13. The system according to claim 11, characterized in that The first computing device includes a host container.

14. The system according to claim 13, characterized in that The operations further include converting the first user-fillable form into a hostable format for the first host container.

15. The system according to claim 14, characterized in that The operations further include receiving an indication of a user action performed in the host container, the user action indicating that the first user intends to communicate with the underlying data source.

16. The system according to claim 11, characterized in that The operations further include: For the dynamic data, query the underlying data source; receiving a query result from the underlying data source, the query result including current data corresponding to the dynamic data; and The first user-fillable form is populated with the current data.

17. The system according to claim 11, characterized in that The operations further include determining that the user is an authenticated user permitted to access a portion of the dynamic data associated with the first data entry.

18. The system according to claim 11, characterized in that The first user-fillable form includes read-only fields and editable fields capable of receiving user-generated data.

19. The system according to claim 11, characterized in that The underlying data source is hosted by an application residing external to the first computing device.

20. The system according to claim 11, characterized in that In response to the first data entry of the first user-fillable form, the dynamic data of the data set from the underlying data source is updated.

Images