WO2011128924A1

WO2011128924A1 - Method for the creation of modular and persistent dynamic web applications with complex interfaces

Info

Publication number: WO2011128924A1
Application number: PCT/IT2011/000109
Authority: WO
Inventors: Andrea Buratti
Original assignee: Andrea Buratti
Priority date: 2010-04-13
Filing date: 2011-04-12
Publication date: 2011-10-20
Also published as: ITRM20100175A1

Abstract

A process for building modular and persistent dynamic web applications with complex interfaces, wherein, there is basically envisaged: initial loading by the client in a single web page in which contained are multiple managements for a complete complex procedural flow, creation of multi -management web pages via the application of a post - generation technique and rendering thereof directly on the client, providing them with specific intelligence and complex objects and converting them into web applications self -post-generation and dynamic rendering of portions of application directly on the client, following upon interaction with the user; subsequent local entry by the user - of all the required data, also via synchronous/asynchronous calls to additional and possibly necessary services or web pages; validation - locally and where it is not possible by means of sending to/receiving from the server of strings of characters regarding additional information - of the totality of the data entered; overall sending to the server of the data entered and validated, prearrangement of the page for subsequent uses by means of local initialization on the client of the both visible and non-visible objects.

Description

PROCESS FOR BUILDING MODULAR AND PERSISTENT DYNAMIC WEB APPLICATIONS WITH COMPLEX INTERFACES

k ~k ~k "k "k

The present invention basically relates to the sector of web communications via the Internet, in which there -is necessary an exchange of data between a local user (referred to as "client") and a remote server, which are connected to one another via the Internet.

More specifically, the invention regards creation of a technology that is innovative with respect to the current state of the art, which enables passage from a programming for navigation between single pages not physically linked to one another but connected by logical references and remote processes to a web- application technique that is dynamic, ^' - modular, persistent, on^' a single multifunctional page, downloadable upon request, in order to obtain that the amount of data exchanged between the remote server and the local client will be reduced by from 60 .to over 200 times, achieving a speed and ease of execution that are incomparable as compared to current technologies, thus revolutionizing the world of the web not only from the standpoint of analysis and development, but also from the standpoint of use, enabling fast interactions, with advantages both from the functional point of view and from the^' economic point of view.

Currently, the main problem of an application of any nature is the binding between the information, i.e., the data, and its graphic representation performed keeping said data distinct and separate.

Said problem- has been solved in a satisfactory way for applications that are installed directly on a computer (which . are referred to as "desktop applications" and which frequently require execution of a process of installation of the program on the user machine) , but has not been tackled in a satisfactory way for applications that run in a separate environment and do not require any installation, such as web browsers.

The main purpose of the present invention is hence to overcome the problems mentioned above by means of a process designed to reduce drastically the amount of data and web pages exchanged between a remote server and a local client during supply of information.

The above has been obtained, according to the invention, by providing a process that functions as keystone and that basically envisages:

- grouping of multiple managements, regarding a complete comple procedural flow performed on a single web page by the client, so that the same page is loaded once and for all for the whole life cycle of the ^'entire session of the website;

- application of a post-generation technique and rendering of the web pages directly on the client, providing. them with specific intelligence and complex objects and converting them into web applications proper, with a reduction in their volume of more than 50%, and with processing on the part of the server reduced to the minimum; in this way, the server no longer has to perform (or performs to a minimum extent, i.e., to an extent of around 5-^' 10% with respect to normal techniques) merging of the server languages with HTML and data, achieving a good separation between the server, client, and data layers;

- subsequent entry by the user of all the required data, also via synchronous/asynchronous calls to additional services or web. pages that may possibly be necessary for completion of the information;

- local validation performed in a global and overall way, but at the same time in an atomic way, of the totality of the data entered/modified;

- complete sending to the server of the heterogeneous mass of just the data entered and validated, and not of the web pages, only following upon request by the user.

A better understanding of the invention will be obtained from the ensuing detailed description and with reference to the attached figures, which illustrate,purely by way of example, a preferred embodiment.

In the drawings :

Figure 1 represents the analysis of a flow and a navigation scheme >with current technology (represented squared are the web pages) ;

Figure 2 represents the analysis of a client- acquisition process with a request for financing with current technology (represented squared are the web pages) ;

Figure 3 represents the web-page operating scheme with the technique of submits of a page on itself; Figure 4 represents the web-page operating scheme with the techniques of javascript and submits of a page on itself;

Figure 5 represents the web-page operating scheme with .net advanced platform and AJAX functions;

Figure 6 represents the analysis of a process for entering mortgagee demographic data with the new technology (represented squared is the single multifunctional web page and the server page) ;

Figure 7 shows the scheme of link between the HTML areas and subsequent processing and post-rendering by the Client Core;

Figure 8 shows the scheme of link between an HTML page and the XML configuration file;

Figure 9 represents the mapping of the structure (fields and sections) of an HTML page with the onLoad section of the XML configuration file linked to said HTML page;

Figure 10 shows the link between the HTML areas and the data-exchange structures present in the XML file;

Figure 11 is a summary scheme of operation of the Client Core when interpreting the onLoad section and of rendering of a web page;

Figure 12 shows an HTML page and a scheme of the page structure, the link with onLoad . and Data sections of the configuration file, and the result of ABUCore processing;

Figure 13 represents the operating scheme of the dynamic creation of a portion of page in complex objects within a caller complex object; Figure 14 shows an example of operating scheme of a complex process with current technology, highlighted in which is the link between the individual pages and the corresponding portions of data;

Figure 15 represents the operating scheme according to the new technology, as well as assignment of the various areas to the multifunctional page;

Figure 16 shows operation of the new technology with advanced components capable of performing complete managements and validating the data automatically;

Figure 17 represents the operating scheme with the new technology for a simple page for display and management of demographic data;

Figure 18 represents the link between HTML code, XML configuration, events, and user code associated to an event, and the final result;

Figure 19 represents an example of writing of a portion of web page, the definition of a complex object, and the linked user function (HTML, XML, Javascript) ;

Figure 20 represents the operating scheme with the new technology of an advanced component able to include heterogeneous managements and create flexible data structures on a single web page;

Figure 21 represents the passage from a normal page to a multifunctional rendered page, and thence to modular dynamic web applications that can be downloaded upon request;

Figure 22 represents properties, methods, and events that have in common . the types of objects read, write or called by the Client Core;. Figure .23 shows the HTML page editor and the configuration file: note the link between the HTML and the XML file, and the dynamic generation of the XML tags in the second image;

Figure 24 shows key elements of the technology of persistent, modular dynamic web applications on single multifunctional page.

The current mode of programming on the web is based upon a concept of pages correlated by logic processes, with data that are exchanged with the server and stored within the pages themselves, on cookies, sessions, variables, server classes, etc., up to completion of the logic process, during which the data are effectively stored in a persistent way (Figure 1) . The various pages have always treated small portions of information with more or less partial managements (Figure 14), for completing which navigation is performed on other pages or windows are opened with other, pages inside or pages are created that contain other pages or that recall themselves in order to be able to carry out the various managements. Represented in Figure 1 is a simplified flowchart of a web application of a known type with a process made up a number of managements. Even without wishing to execute a complete flow and adopting a different scheme, the number of pages and managements is quite large.

There are processes that require acquisition of a complex data structure to be able to yield an "outcome" to a processing. Represented, once again in a simplified way in Figure 14 is the amount of pages that are necessary to complete the data structure represented on the left during^■ an entry process of a known type. The example regards three structures, a main one for the primary process, and two structures for sporadic calls on the server to retrieve or check data. The number of pages required with current technologies, for a simple operation of this type, is approximately eight (with corresponding checks on navigations, data in session or in temporary data structures, calls for data completion or display, management of navigation, check on the data entered, etc.) . If a complete management is considered for each structure, the project becomes tremendously complicated, not only as regards its creation but also in terms of use and amount of pages (data, HTML, images, etc.) that have to be exchanged.

Another consideration to be made . regards the techniques with which to tackle the problem of a single management. Suppose we have a page that enables a complete management (entry/modification/ management/search) : this not only would have to carry out retrieval of the information, but also validation thereof .

The approach could be to adopt one of the following techniques:

□ entrusting . to the server all the operations, including those of validation, performing cycles always on one and the same page (page submits), on which the state-machine technique will be implemented, i.e., storage of the current state of the page (Figure 3) ;

□ opting for a data validation on the client and subsequently sending the page to the server with a technique similar to the previous one, or else applying the more sophisticated one of asynchronous, calls to the server and managing everything manually (Figure 4;) ;

□ possibly using advanced platforms, such as for example "microsoft.net" with the application of techniques of asynchronous calls (AJAX) , shifting the programming operations onto the. server and working on the respective mapped objects, with, which it is possible to interact as on the client and also carry out operations of binding of data to the components (server-side data binding) , and subsequently, at the end of the operations, the framework will carry out rendering of the information in the web format replacing the old HTML code with the new HTML code portions (Figure 5).

The techniques set forth above are the ones used with the most common development languages (asp, php, java, microsoft.net, etc.) used as such or in addition to frameworks, of their own or of third parties. External components could be used (to be installed on browsers as if they were extensions), which represent parallel development environments and enable interactions that are interesting above all from the graphic standpoint.

The problem, however, is that said techniques shift the programming onto other proprietary platforms and languages and . in any case cannot be employed in uses of this kind on account of the burden of the application packages (these are in any case external applications , that are displayed on a web page and have to be physically downloaded into the client machine) .

Creation of a management software is currently still rather complicated, even with modern development tools, with which actual control is also lost and the user has no direct contact with the written code and is unaware of the overloading that is caused to the web and to the server for simple processing operations that at times are to be carried out exclusively by the client. Creation of complex projects like finance management, tax ascertainment, process fl^'ows, hospital management, or the like, is ah operation that is for say the least problematical on account of the considerable amount of data that have to be treated, displayed, exchanged, and processed for the individual processes of analysis (Figure 1, . Figure 14).

Another very burdensome problem for current complex processes on the web (with many pages to be filled in to complete the operations, such as, for example, a process for request for an estimate of financing on the part of a new client) , regards keeping track, displaying, treating, and storing the data when an incongruence or an error that can be detected only at the end of the process arises, due for example to a partial or erroneous filling-in of an intermediate page. This is burdensome not only for the user, who has to start navigating backwards, but also for the server, which must repropose the various pages with the corresponding data until the desired point is reached, with the added problem that the user then has_. to navigate again forwards with further overloading and waste of time (Figure 2) . In the unlucky case where there is 'an even slight malfunctioning there is a very high risk of losing all the work carried out, with the need to start all over again re-entering the data.

In the light of the problems mentioned above, and starting from the current technologies, according to the present invention a technique has been developed that makes it possible to eliminate all the critical points of a traditional web application and to:

• eliminate totally the need to navigate between pages of a website;

« eliminate the problem of storage, retrieval, and representation of the data in the various pages;

« facilitate and speed up organization, representation,. and use of . the information displayed;

• eliminate any useless exchange of data between the client and the server;

• include dynamic technologies of synchronous/asynchronous calls for exchange of information;

• group the largest amount of information on a single page;

• display a considerable amount of information on the client;

• exchange and treat large amounts of data between the client and the server;

• prevent as much as possible installation of software on user machines;

• separate as much as possible the link between the pages and the data; • reduce to a minimum writing of information of the HTML tags, limiting this only to the identifier thereof and to the styles to be applied;

• reduce to a bare minimum, i.e., to a few rows, the code to be entered for formal checks;

• create "smart" objects, each of which is not only able to interact with the user, but also to contain, control, and validate the data for which it is responsible and to exchange said data with the outside world (client-side data binding) ;

« avoid the need to write code for the objects within the pages;

• sort and process the mass of information exchanged between the client and the various server processes .

The present invention provides a technology that enables concrete . implementation of the concepts referred to above, creating a "Client Core" that functions as "orchestral conductor" of the system: starting from a pure page written in simple HTML (which can be generated also with a php, asp, .net, java, or the like) and . from an external configuration file linked thereto and written in XML, the "Client' Core" carries out analysis and generation of the code necessary for creating the web application (Figure 7). This technology, and the corresponding implementation, moreover provides the advantages listed below.

■ The software created is easily developed, maintained, and scalable.

■ Thanks to the client techniques of automatic data binding of the objects, notwithstanding the large amount of, data exchanged, the speed is extremely high, even on very slow networks. Comparing the heterogeneous mass of data exchanged according to the invention, which may be at the most around 5/10/15 KB, with the mass of data that there is normally with a traditional navigation and that, considering pages, data, and images, can range from a minimum of 300 KB to 1 MB or more, a ratio of reduction of the data exchanged is reached ranging from 1:60 up to over 1:200! This implies lower loading of the servers, considerably shorter response times, nimbler processing operations (Figure 15) .

The network traffic is lower, and the processing operations by the server are reduced to a minimum, hence with high response speeds, thanks to the persistence of the web pages, _ which will be downloaded only once by the client irrespective of the use and the calls made, thus implementing the concept of "modular web application downloadable, upon request". In this way, according to the invention, once a portion of application has been loaded and rendered on the client, it will no longer be necessary, to reload it at each subsequent request, and it will be possible to pass in real time and without waiting times from one web application to another, always an exclusively remaining on a single page and on the client machine. Working on the web, by applying the data- binding techniques, the changes made on the data will be visible also on the other web applications that have. already been loaded by performing a simple updating of the data (not of web page) in the case of preloaded data (grids with the data of search that has already been made and loaded), or else in real time in the case of requests without permanence of data on the pages (calls in real time for checks of congruence, selective loading of data in objects, etc. ) (Figure 21) .

■ The Client Core of the system generates a postgeneration and post-rendering directly on the user's client (Figure 7), thus providing a processing that is far nimbler and faster on the server and a reduction of written code by more than 99%; with this technology, also possible is a different generation of the code according to the receiving device. To render everything more flexible, there is the possibility of generating via server the XML configuration file (second image of Figure 23), with languages as php, .net, java, etc., thus opening the way for a further series of other opportunities (for example, avoiding the need to generate the source code for all the management calls made to the server and limiting. the objects to just display of the data for users not enabled to perform updating operations ) .

» The parallel configuration in an XML file enables even a person who is not highly skilled to use the invention, given that he simply has to set tags and properties to create his own project. Furthermore, any technical details of internal implementation, i.e., the correct writing of the entire complex code necessary. to create the web application, via self- post-generation by the Client Core, and the objects themselves, is totally transparent to the user; the objects and the Core automatically self-generate both the code and the portions of web page following upon user actions (Figure 18, Figure 19, Figure 23) . ■ Given that the method according to the invention is based upon a programming on tags, via integrated graphic editors, it is possible to act independently on the new objects, or on the standard ones by adding new properties to those already existing of the basic tags in such a way that the developer does not need to bother where the information for obtaining advanced behaviours is written (Figure 18, Figure 23) .

According to a peculiar characteristic of the invention, the XML configuration file contains within it a structure divided into specific logic areas, for example four logic areas (Figure 8), which may also be extended and modified for future needs.

. Dialogue area: defined in this section are all the dialogue areas that will serve to communicate with the server. Each area has an identifier of its own, and the fields and objects indicated therein, with their own names or with an alias, map the respective objects present on the page (Figure 10, Figure 19, Figure 23). These areas represent the heterogeneous mass of data that will be exchanged with the server. Whenever there is used a specific area to be sent to the server via, for example, an AJAX call, the Client Core, after having ascertained completeness of the data, will. create said structure (Figure 15). In the definition of the structures, there may be specified information regarding the type of datum, the length, as well as formatting, or events. to be performed for pre-assignment or post-assignment checks, also enabling interfacing of the areas with languages, such as Cobol, that . send the strings - (the data) in text format. Present in Figure 10 and Figure 12 is a graphic example of data structures and mapping of these with the objects of a web page, whether standard objects or advanced ones. The data structures will be passed to the server in the form of serialized objects according to the JSON format, but the creation of XML structures, either in simple strings of text or in other formats that may be specified as desired, is not ruled out.

Page-initialization area: indicated in this section (Figure 19, Figure 22) are all the fields that will have a particular behaviour, which can range from an entry mask to an initialization of values, to the definition of a compulsory field, to the specialization of a field (date field, tax-code field, VAT-number field, etc.), with corresponding checks of validation that can be extended by users, to a rendering of a complex object in an area indicated (Figure 7, Figure 12, Figure 19). An interesting characteristic of the Client Core is the possibility of defining simply an HTML area with an identifier and indicating in the configuration file the structure of the complex object to be created therein (Figure 18, Figure 19). In the definition of the complex objects (grids, repeaters, treeviews, etc.) it is possible to indicate the input objects that will have to be used during the. steps of entry/modification/display of the data, in addition to their respective formatting, compulsory fields, and rules of validity and events (Figure 16, Figure 18, Figure 19). Another interesting characteristic is the possibility of entering not only advanced objects, but also areas that in turn have to be rendered with advanced objects, formattings, calls to the server, etc. (Figure 13), and always dynamically and on the client. In some advanced components (see Figure 20, which regards a TreeRepeater ) , it is not ^■ only possible to specify the type of area and of objects to be associated but also the compulsoriness or otherwise and the number of repetitions of the areas, enabling generation, in a single component and in a single page, of multiple heterogeneous managements and variable structures.

Actions: defined in this section are the various synchronous/asynchronous calls that have to be made to interact with the server. Also indicated are the areas to be checked and sent, the names of the variables with which said areas travel to the server, the type of said data, and the possible actions to be undertaken^' before and after sending and receiving the data (Figure 19) .

Actions on user interface: defined in this section are actions that must arise following upon user interaction, for example enabling/disabling of fields, etc. The fulcrum of the invention basically lies in the Client Core (ABUCore) , which performs different operations that can be listed schematically as follows (Figures 7 to 13) :

1. loading of libraries of basic, generic, and advanced functions, including extensions of functions of the standard objects and classes for check on the data (validation, masks, check on change of data ^j areas, and the like) ;

2. reading of the configuration file associated to the page and storage thereof;

3. analysis of the components that will have to be used for proper operation of the page, and loading thereof, avoiding loading of libraries that are not required;

4. once it has been ascertained that loading is through, reading by the Client Core of the initialization section of the page, i.e., of that logic portion of the configuration file defined in which are the objects that will have to be created upon loading of the page;

5. generation of the code for initialization, formattings, user inputs, and validations;

6. generation of the code for grouping the required and compulsory fields according to particular modalities: a field marked as "required" belongs to a group of fields that are marked as such- and that have to be all filled in by the user; it is possible to envisage different groups of required fields, which are equivalent to different sets of fields grouped together; when validation is required, the set of the groups of fields will be checked; it is also possible to envisage that a field is required following upon given conditions; if a group of fields is defined as "compulsory", this means that, if not filled in, it does not generate an error, but if at least one of the fields is filled in, then necessarily the entire group must be validated; also in this case, there may be conditions of activation that can be applied;

generation of the code of the complex objects, excluding all those that are included within the repeaters; for^' each object defined in an object, the respective code will be generated as per points 5 and 6;

generation of the code for the synchronous/asynchronous calls, and for importation and exportation of the data on the basis of the areas defined in the purposely provided section, converting the data from text format to an object format, and vice versa (serialization and deserialization) ; if so required, the code for validation is also generated;

generation of the code of the area of the actions on the user interface;

in the case of repeaters, generation by the Core, according to the objects and in a preventive way or else upon request by the caller object, of the code for creation and functioning of all the objects included therein, as per points 5 to 9.

Also implementable are advanced tools for printing the web with said technology, making it to interact and integrating it with writing tools, such as Microsoft Office, to enable dynamic web prints to be made, client side, with reports created by the user with Word or Excel with data coming from remote, also enabling further processing^' operations on the data themselves.

To enable proper operation of the system, the complex client objects must be provided with some common characteristics that can be configured and recalled by the Client Core (Figure 22):

1. they have to know who they are and what they are called;

2. they have to know who. is the Client Core that has generated them and to which they have to send subsequent queries;

3. they have to know whether complex objects of a ( self-generating) repeater type are recalled and what suffix to apply;

4. they have to declare their state (normal or editable) ;

5. they have to declare their change;

6. they have to know how to import and export the data according to the formats established;

7. they have to know how to carry out a mapping of the data; i.e., the names of the data to be imported/exported may differ from those to be used;

8. they have to know the changes that have been made on the data assigned thereto (new/modified/eliminated) ;

9. they have to execute the code for creating the formattings, compulsoriness , or complex objects during the passage in editable mode;

10. they have to enable retrieval from outside, in a convenient way and according to the names assigned by the user, of the information of the data contained therein, in order to be able to make calculations and checks outside the objects;

11. they have to declare events and provide the possibility of writing the code to be executed following upon user actions on the object, such as, for example, a confirmation of the data entered (Figure 18) ;

12. the more complex objects of a repeater type enable pointing from outside, in a convenient way, both of the HTML objects created dynamically, and of just the values (Figure 19) ;

13. the more complex objects of a repeater type either modify automatically the code for automatic generation of the internal objects or even query the Core (once again client side) and get the entire code to be generated, not only the code for formatting, but also that for rendering, validation, ¹ synchronous/asynchronous calls, or the like is necessary to get the new area/portion of application required to function properly.

The task of the Server Core (Figure .15) is simpler, in so far as, in the example illustrated:

1. it carries out serialization/deserialization of the data exchanged, i.e., conversion from, the format sent as text to the object format, and vice versa;

2. it carries out sorting and grouping of the heterogeneous mass of data from and to the various specific classes, applying the actions impressed on the data by the client;

3. it also carries out automatic generation of the queries and their merging with the data; with this system actions .are performed on the database only following upon user actions; as an alternative to generation of the queries, it is possible to sort the data and to interface with other systems on the basis of the various RDBMS technologies.

Furthermore, according to the invention, it is also possible to carry out again the checks of client validity also on the server on the basis of the centralized configuration file.

According to the present invention, the method for writing a web page to which said technology can be applied in order to convert it into a dynamic web application with complex interfaces is advantageously very simple (Figure. 12, Figure 18, Figure 19) and envisages the following steps:

A) the tags are written in a very elementary way avoiding addition of any information beyond the identifier and the class of style to be applied (Figure 18, Figure 19, Figure 23);

B) simple tags that are containers for the complex objects that it is desired to use are written, specifying the identifiers thereof, which must be unique (Figure 18, Figure 19, Figure 23);

C) the standard HTML objects that must be used within complex objects, as input thereof,, must be defined^' outside the containers (combos external to the grids, Figure 18); D) the various containers must be positioned in such a way that the objects that are to be contained are already positioned inside them (this is not always necessary, because the Core automatically moves the objects) (Figure 7 before rendering, Figure 9, Figure 12, Figure 20) .

E) the basic tags with their corresponding formatting, classes of compulsoriness , events, initializations, or the like are written in the onLoad section of the XML file (Figure 9, Figure 19, Figure 23) .

F) the identifiers of the complex-object tags are written in the onLoad section of the XML file (Figure 11, Figure 12, Figure 19), specifying the type, structure, and events thereof and defining for each field contained therein an identifier for mapping of the data-exchange fields and the rules of formatting and compulsoriness and events that will arise upon confirmation or during a change (Figure 16, Figure 18); in the case of complex objects that include other complex- objects, it is sufficient to specify the identifier of the complex object to be rendered, and this is automatically sought by the Core and included therein (Figure 13, Figure 19);

G) the data structures are written in the section of the dialogue area, indicating the unique identifier of the area; both for simple objects and for complex^' ones it is sufficient to indicate the identifier and possibly an alias; in the case of complex objects that exchange a great amount of data, the identifier will represent the name of the entire data section to which they belong; in this simple way, it is possible .to obtain heterogeneous complex data structures (Figure 10, Figure 12, Figure 15, Figure 19, Figure 20) ;

H) the definition of the calls, the type of call (synchronous/asynchronous), the parameters and the areas for the data (of the section of the dialogue area) to be passed are written. in the section of the actions, indicating, if necessary, the validation, in addition to the functions or portions of code to be executed before and after sending and receiving them (Figure¹19) ;

I) the changes of state of the objects displayed following upon user actions and possible actions to be undertaken are written in the section of the actions on the user interface.

This innovative^' process according to the invention is advantageous as compared to current methodologies and technologies because it enables elimination of a multitude of pages linked to one another only by a logic process (Figure 1, Figure 2), finally obtaining a one-to-one relation between the logic process and the web page (Figure 6) .

Any complex process, as described above and represented schematically in Figure 14, with the present invention and the ABUCore, which is the central framework, i.e., the heart of the system that coordinates and generates the code of the entire web application, can be enclosed in a single multifunctional . page with purely dynamic exchange of data (dynamic client-side data binding) (Figure 15, Figure 20) . Unlike . what is known, the objects created dynamically according to the invention map portions of HTML areas with portions of data. Each object is responsible for its own data, for display, entry, modification, elimination, validation, and exchange (Figure 18, Figure 19) . In addition, when it is necessary to make a transmission of an area that concerns a multitude of objects, the Core queries each smart object to know the state thereof (Figure 16 and Figure 17) and only in the case of affirmative answer, the objects can be taken and their data packed to create the desired structure (Figure 15). This conveniently enables representation of large structures of heterogeneous dynamic data and precise control thereon.

Another peculiar characteristic of the invention is the dynamic creation of web objects directly client side, without any interaction with the server: there are numerous components that carry out dynamic creation of objects directly on the client machine, for performing functions of entry/modification/elimination of a record (Figure 16, Figure 18, Figure 19); there are also components that enable dynamic duplication of entire areas (with the corresponding managements, checks, and ^'calls to the server with data exchange) directly on the client and in real time (Figure 13, Figure 19, Figure 20); in any case, the modifications will remain on the client until the data are sent by the user to the server.

With the process so far described, it is possible to carry out a complete management, which previously was carried .out by a page (Figure 14), via a single component (Figure 13, Figure 16, Figure 19) . It is even possible to create smart objects, such as the repeaters, with which it is possible to duplicate the action of a number of pages with various managements in a single component (Figure 19) .

With the new technology developed according to the present invention, it is possible to perform on the web managements that so far were deemed impossible to create on a single web page, and everything is englobed in a single component.

Consider, for example, a request for financing made by a user, which schematically envisages the following steps:

1. Acquisition of- user demographic data

2. Acquisition of telephone numbers

3. Acquisition of user assets and property

4. Acquisition of user income with annual calculation of earnings

5. Acquisition of user expenditure with corresponding calculation

6. Acquisition of the different types of financing (estimates') selected by the user (from one to as many estimates the user desires) .

In the case where there is a spouse, it would be necessary to repeat steps 1 to 5 for acquisition of new data, and the same for the guarantors and sureties. Is it possible to group a management that is so complex on a single web page with current technologies? With the present invention, represented in Figure 20 is a TreeRepeater (the same idea can be implemented also for building any. other interface or component) provided with capacity to associate different areas to each branch. Each area may be compulsory or optional and can be repeated a number n of times; it is possible to include therein advanced components and implement all the concepts described above.

With the innovative method described,, which is particularly advantageous for tackling and solving web problems, it is possible to create the above interface even in a single component, capable of creating heterogeneous and flexible data structures, according to use, acting always and exclusively on the user's client!

Once a complex client page has been created, which can contain simultaneous managements inside it, just as in the case of a true desktop management application, the data that will travel between the (local) client and the (remote) server have the characteristic of travelling in a compact and modular way. According to the invention, it is an appropriate framework (referred to as Server Core) present on the server that carries out sorting of the information coming from the client, its assignment to structures suitable for the processing to-be carried out, and recompacting of the incoming structures to be sent back to the client (Figure 15) .

In order to convert a dynamic web application with a rich graphic interface of a known type into a dynamic web application that is modular, persistent, downloadable upon request, and with rich graphic interface according to the present invention, it is sufficient to provide the main page of the site with a component that englobes and preserves the various web pages, in practice that behaves like a small browser (for example, an iframe) . By associating the attribute of visibility or non-visibility to any web object, that englobes the various web pages in the main page, we shall obtain the persistence of the corresponding portions of application (Figure 21) .

The client framework or Client Core (ABUCore) that is described, written in pure Javascript, upon loading of a page . analyses the configuration file thereof, includes just the required libraries and waits for loading thereof, generates the entire code necessary for rendering of the complex objects, for control, and for functioning of the page, in addition to all the synchronous and asynchronous calls with the corresponding structures (Figure 7), converting a simple HTML/XHTML page into a rich dynamic client-side web application (Figure 21) .

The server framework or Server Core is far simpler in so far as it is provided with some classes that perform sorting/grouping of the data, in addition to assignment of these to the various queries, which, being written in a proprietary and parametric format, enable automatic writing thereof, without any intervention of analysis by the user for the data that are present or absent.

To sum . up, in order to enable creation of persistent, modular, dynamic web applications that can be downloaded upon request and with rich client interfaces there is envisaged the use, in combination, of the following elements with the following characteristics (Figure 24):

A. providing a web page and an XML configuration file associated thereto which is internal or external to the page, written in any format that can be interpreted by an appropriate Client Core, here referred to also as ABUCore;

B. providing said Client Core or ABUCore, which interprets the XML configuration file associated to the page for generating the code;

C. creating smart dynamic components provided with client-side data binding, techniques of validation and data exchange, technology for automatic and dynamic generation of HTML code, which interact with the Client Core for subsequent processing^" or queries;

D. providing the capacity for creating complex data structures with JSON format, XML format, or the like;

E. providing synchronous and asynchronous calls via AJAX.

These elements together function as "keystone" for the creation of said technology. In fact, if any one of them were to be eliminated, the structure would fail, and it would no longer be possible to generate the vast multitude of possibilities described above.

□ By eliminating the (external or internal) XML configuration file, also the Core ceases to have any reason to. exist. It would be possible to write the entire code by hand, but the hundreds of rows that would have to be produced would not lead to the full result, since it is not possible to generate upon request further code during the dynamic generations of the smart components.

By eliminating the Core, also the parallel configuration file ceases to have any reason to exist, which leads to the previous condition.

By eliminating the dynamic smart components, all the possibilities of advanced pages, complex structures, and exchange of data vanish.

By eliminating the complex structures, the advanced components would be reduced to purely visual components, and it would be very burdensome, if not even impossible, to retrieve and recognize the data amongst a myriad of HTML tags, styles, and external code.

By eliminating the synchronous/asynchronous AJAX calls, the dynamicity and the persistence of the pages would be lost and the old navigation techniques would have to be re-applied.

This technology is possible purely on account of the great flexibility of the web browsers and of a language, such as Javascript, which in its simplicity has a power and a flexibility that is hard to achieve, if not even unthinkable, in many other even advanced languages. Certainly, an evolution of the language will imply considerable transformations on said technology, which are so far unforeseeable.

Claims

1. A process for building modular and persistent dynamic web applications with complex interfaces, characterized in that, in order to reduce drastically the amount of data and web pages exchanged between a remote server and a local client during supply of information, it substantially envisages:

- initial loading by the client in a single web page that functions as container for the other multifunctional pages, grouped together in which are multiple managements for a complete complex procedural flow, and which can be recalled upon request by the user, with a single loading thereof for the whole life cycle of the entire session of the website;

- creation of multi-management web pages via the application of a post-generation technique and rendering thereof directly locally on the client, providing them with specific intelligence and complex objects and converting them into web applications proper, with a reduction in their volume of more than 50%, and with processing on the part of the server reduced to the minimum and to an extent of around 10% with respect to current techniques ;

- self-post-generation and dynamic rendering of portions of application (HTML, client code, synchronous/asynchronous calls, advanced checks, or the like) , also of a multi-management type, directly on the client, following upon interaction with the user; - subsequent entry by the user - locally and without exchange of data with the server - of all the required data, also via synchronous/asynchronous calls to additional and possibly necessary services or web pages;

- validation - locally and where it is not possible by means ^' of sending to/receiving from the server of strings of characters regarding additional information - of the totality of the data entered;

- overall sending to the remote server of the heterogeneous mass of just the data entered and validated, and not of. the web pages, only after completion of entry by the user, with a ratio of reduction of the data exchanged of from 1:60 up to over 1:200;

- prearrangement of the page for subsequent uses by means of local initialization on .the client of the both visible and non-visible objects, whether simple or complex .

2. The process according to the preceding claim, characterized in that it envisages:

A. providing a web page and an XML configuration file associated thereto, which is internal or external to the page and is written in any format that can be interpreted by an appropriate Client Core;

B. providing a Client Core, or ABUCore, which interprets the XML configuration file associated to the web page for generating the code;

C. creating smart dynamic components that are provided with client-side data binding, techniques of validation and data exchange, technology for automatic and dynamic generation of HTML code and Javascript and that interact with the Core for subsequent processing or queries or self- generation: HTML,. client code, synchronous/asynchronous calls, advanced checks, or the like;

E. providing synchronous and asynchronous calls via AJAX .

3. The process according to the preceding claim, characterized in that said Client Core, or ABUCore, performs at least the following operations:

1. loading of libraries of basic, generic, and advanced functions, including extensions of functions of the standard objects and classes for control on the data, such as for example: validation, masks, check on change of data areas, etc . ;

2. reading- of the configuration file associated to the page and storage thereof; .

3. analysis of the components that will have to be used for proper functioning of the page, and loading thereof, avoiding loading libraries that are not required;

4. once it has been verified that loading is through, reading by the Client Core of the initialization section of the page, i.e., of that logic portion of the configuration file defined in which are the objects that will have to be created upon loading of the page or to which particular behaviours will . have to be associated;

5. generation of the code for initialization, formatting, user inputs, validations;

6. generation of the code for grouping the required and compulsory fields according to the particular modalities: a field marked as "required" belongs to a group of fields that are marked as such and that must be all filled in by the user; as regards the "compulsory" fields, if one has been filled in, they all have to be filled in group;

7. generation of the code of the complex objects, excluding all the ones that are included within the repeaters: for each object defined in an object, the respective code will be generated as per points 5 and 6;

8. generation of the code for the synchronous/asynchronous calls, and for the importation and exportation of the data on the basis of the areas defined in the purposely provided section, by converting the data from text format to an object format, and vice versa: serialization and deserialization;

9. generation of the code of the. area of the actions on the user interface;

10. in the case of repeaters, generation by the Client Core, according to the objects and in a preventive way or upon request of the caller object, of the code for creation and functioning of all the objects included therein according to points 5 to 9. ^'

4. The process according to Claim 2 or Claim 3, characterized in that said XML configuration file contains within it a structure divided into at least four logic areas :

1) Dialogue areas: defined in this section are all the dialogue areas that serve to communicate with the server, each area has an identifier of its own, and the fields and the objects that are indicated therein, with their own names or with an alias, map the respective objects present on the page;

2) Initialization areas: indicated in this section are all the fields that will have a particular behaviour, which can range from an entry mask to an initialization of values, to the definition of a compulsory field, to the specialization of a field, such as, for example, a data field, a tax-code field, a VAT-number field, etc., with corresponding checks that can be extended by the users to a rendering of a complex object in an area indicated;

3 ) Actions : defined in this section are the various synchronous/asynchronous calls that have to be undertaken for interacting with the server, the areas to be controlled and to be sent, the names of the variables with which said areas travel to the server, the type of said data, and the possible actions to be executed before and after sending and receiving of the data;

4) Actions on user interface: defined in this section are actions that must arise following upon user interaction, for example enabling/disabling of fields, etc.

5. The process according to the preceding claim, characterized in that it envisages the following steps:

I. the tags are written in a very elementary way avoiding addition of any information beyond the identifier and the class of style to be applied;

II. simple tags that are containers for the complex objects that it is desired to use are written, specifying the identifiers thereof, which must be unique ;

III', the standard HTML objects that have to be used within complex objects, as input thereof, for example the combos external to the grids, are defined outside the containers;

IV. the various containers are preferably positioned in such a way that the objects that must be contained are already positioned inside them before rendering, such as for example the panels within tabs;

V. the basic tags with their corresponding formatting, classes of compulsoriness, events, initializations, or the like, are written in the onLoad section of the XML file;

VI. the identifiers of the complex-object tags are written in the onLoad section of the XML file, specifying the type, the structure, and the events thereof and defining for each ^' field contained therein an identifier for mapping of the data- exchange fields and the rules of formatting and compulsoriness and events that must arise upon confirmation or during a change; in the case of complex objects that include other complex objects, it is sufficient to specify the identifier of the complex object to be rendered, and this is automatically sought by the core and included therein;

VII. the data structures are written in the section of the dialogue area, indicating the unique identifier of the area; both for simple objects and for complex ones it is sufficient to indicate the identifier and possibly an alias; in the case of the complex objects that exchange a considerable amount of data, the identifier will represent the name . of the entire data section to which they belong; thus obtaining heterogeneous complex data structures in a simple way;

VIII. written in the section of the actions are the definition of the calls,. · the type (synchronous/asynchronous) , the parameters and the areas of the data (of the section of the dialogue area) to be passed, indicating, if necessary, the validation, in addition to the functions or portions of code to be executed, before and after sending and receiving thereof;

IX. the changes of state of the objects displayed following upon user actions and possible actions to be undertaken are written in the section of the actions on the user interface.

6. The process according to Claim 4, characterized in that said dialogue areas represent the heterogeneous mass of data that will be exchanged with the server: whenever a specific area to be sent to the server via, for example, an AJAX call, is used, the Core, after, completeness of the data has been ascertained, will create said structure; in the definition of the structures it being^' possible to specify information on the type of datum, the length, as well as formatting or events to be executed for pre- assignment or post-assignment checks, to enable also interfacing of the areas with languages such as Cobol that send the strings, i.e. the data, in text format.

7. The process according to Claim 4, characterized in that the Client Core envisages the possibility of defining simply an HTML area with an identifier and indicating in the configuration file the structure of the complex object to be created therein; in the definition of the complex objects, e.g., grids, repeaters, treeviews, etc., it being possible to indicate the input objects that will have to be used during the steps of entry/modification/display of the data, in addition to their respective formatting, compulsory fields, and rules of validity, initialization, etc.

8. The process according to the preceding claim, characterized in that it envisages the possibility of entering not only advanced objects, but also areas which in turn must be rendered with advanced objects, formattings, calls to the server, etc., and always in a dynamic way and on the client.

9. The process according to Claim 3, characterized in that, starting from a pure page written in simple HTML, which can be generated also with a php, asp, .net, java, etc., and from a preferably external configuration file - written in XML - connected . to the Core, the latter carries out analysis and generation of the code necessary for creating the web application.

10. The process according to Claim 1 or Claim 2, characterized in that it envisages the provision of a Server Core for:

1. carrying out serialization/deserialization of the data exchanged, i.e., conversion from the format sent as text to the object format, and vice versa;

2. carrying out sorting and grouping of the heterogeneous mass of data from and to the different specific classes, applying the actions impressed on the data by the client;

3. carrying out also automatic generation of the queries and their merging with the data to obtain actions on database only following upon user actions; as an alternative to generation of the queries, it being also possible to sort the data by interfacing other systems on the basis of the various RDBMS technologies.

11. The process according to the preceding claim, characterized in that said Server Core carries out sorting of the information coming from the client, its assignment to suitable structures for processing to be carried out, and recompacting of the incoming structures to be sent back to the client.

12. The process according to Claim 1, characterized in that, in order to convert a dynamic web application with a rich graphic interface of a known type into a dynamic web application that is modular, persistent, downloadable upon request, and with rich graphic interface, it envisages providing the main page of a website with a component that englobes and preserves the various web pages, thus behaving like a small, browser, for example an iframe; wherein the persistence of the desired portions of application is obtained by associating the attribute of visibility or non-visibility to any web object that englobes the various web pages of the main page.

13. The process according to Claim 2, characterized in that said Client Core is written in pure Javascript and in that upon loading of a web page it analyses the configuration file thereof, including just the required libraries and waiting for loading thereof, then generating the entire code necessary for rendering of the complex objects, for control, and for functioning of the page, in addition to all the synchronous and asynchronous calls with the corresponding . structures, thus converting a simple HTML/XHTML page into a rich dynamic client-side web application .

14. The process according to Claim 10, characterized in that said Server Core is far simpler than the Client Core in so far as it is provided with some classes that carry out sorting/grouping of the data, in addition to assignment of these to the various queries, which, being written in a proprietary and parametric^' format, enable automatic writing thereof, without any intervention of analysis by the user for the data that are present or absent.