Patent Application
20200326916
Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to being prior art by inclusion in this section.
The subject matter in general relates to the field of software development. More particularly, but not exclusively, the subject matter relates to a framework for rapid software development.
Generally, software applications are developed using imperative languages. Software developers may write code for several components of an application to enable desired functionality. In certain scenarios, the code is application specific and may require enormous amount of code to be written, thereby leading to complexity in the development process. Further, the code tends to be specific to applications, and software developers find it cumbersome to modify or expand the codes written, thereby adding to the time involved in software development.
While there are challenges involved in developing new software or making changes to existing code, there are challenges involved in deploying new or modified software. Generally, the code that is developed or modified need to be compiled, and one or more instances of the server may require restarting to reflect changes. Such aspects of deployment add to the time involved in deploying software. Further, the downtime involved during deployment may negatively affect the end users of the software application.
In view of the forgoing discussion, there is a need for a technical solution to improve software application development and deployment process.
In one aspect a system is provided for software application development. The system comprises at least one processor configured to receive a declarative XML file defining at least a structure of a user interface form. The processer may enable storage of the declarative XML file in a digital repository. Further, the processor may receive a request to render the user interface form on a client device. On receiving the request, the processor may generate the user interface form by referring to the declarative XML file, at each instance request is received to render the user interface form.
In another aspect a method is provided for software application development. The method comprises receiving a declarative XML file defining at least a structure of a user interface form and storing the declarative XML file in a digital repository. The method further comprises receiving a request to render the user interface form on a client device, and in response rendering the user interface form by referring to the declarative XML file, at each instance request is received to render the user interface form.
Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments, which may be herein also referred to as “examples” are described in enough detail to enable those skilled in the art to practice the present subject matter. However, it may be apparent to one with ordinary skill in the art, that the present invention may be practised without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and design changes can be made without departing from the scope of the claims. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated.
Referring to
As an overview, a form may need to be made available by a host application 116 to client devices 114. A declarative XML file 104 defining the structure of the form UI and database, and validations, may be received as an input by the framework engine 106. The framework engine 106 renders the form UI in the host application 100 by referring to the declarative XML file 104 to capture input from users provided via the client devices 114. Further, the framework engine 106 may create SQL table, as per the declarative XML file 104, to persist the data captured. Furthermore, the framework engine 106 may generate SQL query to perform the CRUD [Create, Read, Update, and Delete] operations. The framework engine 106 may also render various types of output in various formats using the renderer engine 108, import and export the data using spreadsheet.
The system 102 may be hosted on a cloud infrastructure within ASP.NET web application as an example, and so can be the host application 116 and third-party integrations 112. An example cloud infrastructure, which can be one or more servers, in which the system 102 may be hosted is discussed with reference to
The processor(s) module 12 may implemented in the form of one or more processors and may be implemented as appropriate in hardware, computer executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) module 12 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described. The instructions that may enable the functionality of the system 102 may be executed by the processor(s) module 12.
The memory module 14 may include a permanent memory such as hard disk drive, may be configured to store data, and executable program instructions that are implemented by the processor(s) module 12. The memory module 14 may be implemented in the form of a primary and a secondary memory. The memory module 14 may store additional data and program instructions that are loadable and executable on the processor(s) module 12, as well as data generated during the execution of these programs. Further, the memory module 14 may be a volatile memory, such as a random access memory and/or a disk drive, or a non-volatile memory. The memory module 14 may comprise of removable memory such as a Compact Flash card, Memory Stick, Smart Media, Multimedia Card, Secure Digital memory, or any other memory storage that exists currently or may exist in the future. The memory module may enable storage of the database 110 of the system 102.
The input/output module 16 may provide an interface for input devices such as computing devices, keypad, touch screen, mouse, and stylus among other input devices; and output devices such as speakers, printer, and additional displays among others. The input/output module 16 may be used to receive data or send data through the communication interface 20.
The display module 18 may be configured to display content. The display module 18 may also be used to receive input. The display module 18 may be of any display type known in the art, for example, Liquid Crystal Displays (LCD), Light Emitting Diode (LED) Displays, Cathode Ray Tube (CRT) Displays, Orthogonal Liquid Crystal Displays (OLCD) or any other type of display currently existing or which may exist in the future.
The communication interface 20 may include a modem, a network interface card (such as Ethernet card), a communication port, and a Personal Computer Memory Card International Association (PCMCIA) slot, among others. The communication interface 20 may include devices supporting both wired and wireless protocols. Data in the form of electronic, electromagnetic, optical, among other signals may be transferred via the communication interface 20.
Referring now to the flow chart in
Below discussed is an example declarative XML file 104 for a simple employee form, which captures details like name, designation and date of birth. This would include definition of the structure for rendering of the form UI, which is based on the declarative XML file 104.
In the above example, <Form> is the root element of the XML. This element provides basic information for the renderer engine 108 and the framework engine 106 to perform their operations.
The declarative XML file 104 may identify a second form UI and data corresponding to a field in the second form UI, which has to be rendered in the form UI.
The <Section> element behaves like a div object in HTML. It provides an enclosure for all controls. There can be more than one section in a form. Sections can include other sections ‘n’ levels deep, and sections can include controls.
The <Control> element is used for all data display in the system. The control provides for data input and corresponding database type and name must be specified. This information will be used to create the required SQL tables.
The <ListColumns> element is used to specify the columns which need to be displayed in the list page.
Moving on, at step 304, the framework engine 106 processes the declarative XML 104 input. As a result of said processing, the framework engine 106, at step 306, creates the necessary SQL tables and views in the database 110. Further, at step 308, instantiates the renderer engine 108 to render the form. The framework engines 106 may also take care of CRUD (Create, Retrieve, Update and Delete) operations.
The renderer engine 108, as an example, renders the form UI in the host application 116, at step 310. It shall be noted that, renderer engine 108 generate or renders the form UI by referring to the declarative XML file 104, at each instance request is received, for example by a client device 114 via the host application 116, to render the form UI. In other words, the code or the XML file 104 is not compiled, instead each time the form UI has to be rendered, the same is created by referring to the XML file 104. Such a feature allows for hot deployment of the new or modified software. The system 102 may store all the declarative XML files 104 required for rendering or creating various forms UI in a digital repository.
In an embodiment, as discussed earlier, the declarative XML file 104 may identify a second form UI and data corresponding to a field in the second form UI, which has to be rendered in the form UI. The renderer engine 108 may refer to the declarative XML file of the second form UI and the table corresponding to the second form UI to render data corresponding to a field of the second form UI in the form UI currently being rendered.
An example list of XML and the corresponding UI representation of various controls enabled by the system 102 or the renderer engine 108 is discussed below.
Example XML that enables the form to submit/post data to server, which is not visible to the end user is provided below.
Example XML that enables display any static text in the form is provided below, and the corresponding UI representation is shown in
Example XML that enables a simple text input field, which can be used to capture alpha numeric characters is provided below, and the corresponding UI representation is shown in
Example XML that enables a multi-line text input control, which can be used to capture alpha numeric characters is provided below, and the corresponding UI representation is shown in
Example XML that enables capture of date in the form by showing a date selection calendar is provided below, and the corresponding UI representation is shown in
Example XML that enables numeric decimals input is provided below, and the corresponding UI representation is shown in
Example XML that enables integer input is provided below, and the corresponding UI representation is shown in
Example XML that enables capture of time input in 24 hours format is provided below, and the corresponding UI representation is shown in
Example XML that enables display images inside the form is provided below, and the corresponding UI representation is shown in
Example XML that enables selection of a single item from a list of available items is provided below, and the corresponding UI representation is shown in
Example XML that allows the user to select multiple items from the list of available items is provided below, and the corresponding UI representation is shown in
Example XML that enables selection of a check box is provided below, and the corresponding UI representation is shown in
Example XML that enables selection of one of the provided options using radio buttons is provided below, and the corresponding UI representation is shown in
Example XML that enables the user to render more than one control one next to other is provided below, and the corresponding UI representation is shown in
Example XML that enables data entry in a predefined format is provided below, and the corresponding UI representation is shown in
Example XML that enables the user to select one or more items from a list of available values is provided below, and the corresponding UI representation is shown in
Example XML that enables password as input is provided below, and the corresponding UI representation is shown in
Example XML that enables check boxes to select values is provided below, and the corresponding UI representation is shown in
Example XML that generates identifier for a form is provided below.
Example XML that enables uploading of documents with the form's data is provided below, and the corresponding UI representation is shown in
Example XML that shows the data in the tree format and the user can choose on or more items from the selected values is provided below, and the corresponding UI representation is shown in
Example XML that allows the user to select date and time together is provided below, and the corresponding UI representation is shown in
Example XML that allows the user to either upload or take new photos using the device camera is provided below, and the corresponding UI representation is shown in
Example XML that shows HTML based text to the end user is provided below, and the corresponding UI representation is shown in
Having discussed about the controls provided by XML and comprehended by the renderer engine 108. We now move on to example list of XML and the corresponding UI representation of various controls containers enabled by the system 102 or the renderer engine 108.
In an embodiment, “sections” provides enclosure to all the controls. There can be more than one section in a form and they can be nested inside sections.
Example XML for a simple section layout having one column and ‘n’ rows of controls is provided below, and the corresponding UI representation is shown in
Example XML for a two column layout is provided below, and the corresponding UI representation is shown in
In an embodiment, “DynamicGrid” provides for a sub table that can have rows added by user input. When using DynamicGrid the user is presented with inline ‘add’, ‘delete’, ‘edit’ buttons that control data entry into the grid (refer
In an embodiment, “StaticGrid” element creates a predefined finite set of rows and columns, having data input and output control in each cell. Different cells in a column can have different type of controls. Refer.
In an embodiment “checklist group” is a container where you can define a set of activities that must be performed in sequence to meet the requirement. All these check lists may have same set of input controls known as “options” for the checklist. Refer
Having discussed the UI resulting from the declarative XML file 104, we now discuss the creation of table and views in the database 110 based on the declarative XML file 104. In an embodiment, the declarative XML file 104 may be published in the host application 116. Once published, the framework engine 106 may create a table and view as per the structure defined in the declarative XML file 104. An example table structure created by the framework engine 106 for a sample form is illustrated in
Moving on to the renderer engine 108, in an embodiment, the renderer engine 108 takes the declarative XML file 104 as input through the framework engine 106 and renders the XML in the desired format.
In an embodiment, an HTML rendering module of the rendering engine 108 renders the declarative XML file 104 in the form of HTML.
In an embodiment, a JSON rendering module of the rendering engine 108 renders the data that is captured in the UI in the form of JSON. JSON format may be used by the integration APIs. Further, the JSON rendering module may render the declarative XML file 104 in JSON format.
In an embodiment, as shown below, an XML rendering module of the rendering engine 108 renders the data that is captured in the UI in the form of XML.
In an embodiment, a report rendering module of the rendering engine 108 renders the report (list page or details, as example) in formats such as PDF or spreadsheet, among other formats.
In an embodiment, the declarative XML file 104 defines an API for integration with third party applications. The APIs can be used to perform the CRUD [Create, Read, Update, and Delete] operations. It may be noted that, for each API request, the processor module 12 may refer to the declarative XML file 104 to perform the CRUD operation. A sample API documentation to create or update instance is provided below.
In an embodiment, the declarative XML file 104 defines a link in the navigation tree (refer
Referring to
Once the mobile application is installed, the application may download data based on the user profile, at step 804. The data downloaded may be based on the permissions granted to the user. As an example, the user may have permission to a set of form and its associated data. The declarative XML files 104 corresponding to those set of forms may be communicated by the framework engine 106 to the client device 114, and stored locally in the client device 114. Further, the application may create tables locally as per the declarative XML files 104 and persist data within those tables.
In an embodiment, a declarative XML file 104 may identify a second form and data corresponding to a field in the second form, which has to be rendered in the form UI. In such a scenario, a declarative XML file required for generating the second form may also be stored locally on the client device 114 and data corresponding to the field, or the entire table of the second form, may be stored locally on the client device. Such data corresponding to the second form may be used when rendering the dependent form.
A user may access the application to request rendering of a form UI, as an example. In response, at step 806, the application may check whether the client device 114 is offline, which means internet access is absent. In case the client device 114 is not offline, then at step 808, the client device 114 or the application communicates with the system 102, as discussed earlier, to address the requests originating from the client device 114.
Alternatively, if it is determined that the client device is offline, at step 806, then the application may rely on the data stored on the client device 114 to cater to the requests of a user. As an example, the user may request a form UI at step 810. In response, at step 812, the application generates and renders the form UI by referring to the corresponding declarative XML file 104 and data stored locally. Any data that is added using the form is stored locally. Further, the application may keep checking whether the client device 114 is back online. Once the client device 114 comes back online, the application syncs with the system 102, causing the data stored locally to sync (two-way sync) with the corresponding table and files stored in the system 102.
The processes described above is described as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, or some steps may be performed simultaneously.
The example embodiments described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.
Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the system and method described herein. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. It is to be understood that the description above contains many specifications, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the personally preferred embodiments of this invention.
