CLIAMS:1. A system for web portal applications, said system comprising,
i. a receiver adapted to receive requests from a user through a web client in the form of an initial request and subsequent requests for performing relevant actions on at least one portlet with/without portlet fragments on a web portal page that comprises a plurality of individually accessible and operable portlets with/without portlet fragments;
ii. an environment switch adapted to receive an initial request from the receiver and further adapted to check, load and switch a web portal application in an environment mode depending on the initial request;
iii. a web client validator adapted to receive an initial request and subsequent requests from the receiver and further adapted to perform automated validations for each element upon the receipt of a request to perform relevant actions on said loaded environment;
iv. a user entitlement checker adapted to receive an initial request and subsequent requests from the receiver and further adapted to perform user authorization check to check if a user is authorized to access pages, portlets, portlet fragments, finest level of fields/elements and backend processes;
v. a master data processor adapted to receive an initial request and subsequent requests from the receiver and further adapted to provide master data to the user node, said master data further comprising:
• a server cache adapted to receive an initial request and subsequent requests from the receiver and further adapted to store master data from external sources;
• a client cache adapted to receive subsequent requests and further adapted to receive and store master data from the server cache based on the received requests;
• a crawler and extractor adapted to receive an initial request and subsequent requests from the receiver and further adapted to crawl sequentially through the client cache and the server cache to extract data requested through the received requests; and
• a filter adapted to receive an initial request and subsequent requests from the receiver and the extracted data from the crawler and extractor, and further adapted to filter the extracted data based on pre-determined filters and the received requests to obtain master data; and
vi. a portlet fragment retriever adapted to receive the initial request and the subsequent requests from the receiver, and further adapted to render/refresh based on the received request, a portlet and/or fragments of portlets , without impacting other portlets or fragments of portlets on the page.
2. The system as claimed in claim 1, which includes an automated template-based json/xml payload generator adapted to receive an initial request and subsequent requests to create json/xml based payloads, and further adapted to send auto-generated json/xml messages to said portlet fragment receiver and/or said gadget retriever and/or external systems.
3. The system as claimed in claim 1, which includes a gadget retriever adapted to receive said subsequent requests from the receiver and further adapted to invoke the portlets and include them as gadgets on remote web portal pages on the user node.
4. The system as claimed in claim 1, which includes a display adapted to receive responses from the validator, the master data processor, the portlet fragment retriever and the gadget retriever and further adapted to display the responses on the user node.
5. The system as claimed in claim 1, wherein said environment mode is selected from the group consisting of development, production, user acceptance testing, local and integration.
6. The system as claimed in claim 1, wherein said web client validator performs validations on the web clients before submitting requests to a server.
7. The system as claimed in claim 1, wherein said validations are selected from the group consisting of mandatory/optional, type, format and length.
8. The system as claimed in claim 1, wherein said web client validator is further adapted to include new custom format validations.
9. The system as claimed in claim 1, wherein said filter must be configured in order to filter said extracted data.
10. The system as claimed in claim 3, wherein said gadgets are remote portlets that can be invoked from authorized internal or external sites based on the received request.
11. A method for web portal applications, said method comprising the following steps:
• receiving requests from a user through a web client in the form of an initial request and subsequent requests for performing relevant actions on at least one portlet with/without portlet fragments on a web portal page that comprises a plurality of individually accessible and operable portlets with/without portlet fragments;
• receiving an initial request from the receiver and checking, loading and switching a web portal application in an environment mode depending on the initial request;
• performing automated validations for each element before submitting a request to perform relevant actions on the loaded environment;
• performing user authorization check based on an initial request and subsequent requests to check if a user is authorized to access pages, portlets, portlet fragments, finest level of fields/elements and backend processes;
• providing master data to the user node based on the received initial request and subsequent requests, said step of providing master data further includes:
o storing master data from respective sources in a server cache based on the received initial request and subsequent requests;
o storing master data from the server cache onto a client cache based on the received subsequent requests;
o crawling sequentially through the client cache and the server cache and extracting data from the client cache and server cache based on an initial request and subsequent requests received through the receiver; and
o checking if the filter is configured and obtaining master data by filtering the extracted data based on an initial request and the subsequent requests received from the receiver.; and
• rendering/refreshing a portlet and/or a fragments of portlets without impacting other portlets or fragments of portlets on the page based on the received initial request and subsequent requests from the receiver.
12. The method as claimed in claim 11, which includes step of automatically creating json/xml based payloads and further includes step of sending the auto-generated json/xml messages to said portlet fragment receiver and/or said gadget retriever and/or external systems.
13. The method as claimed in claim 11, which further includes step of invoking the portlets and including them as gadgets on remote web portal pages on the user node.
14. The method as claimed in claim 11, which further includes the step of displaying the responses received from the validator, the master data processor, the portlet fragment retriever and the gadget retriever on the user node.
15. The method as claimed in claim 11, wherein the step of loading an environment mode further includes the step of selecting the environment from the group consisting of development, production, user acceptance testing, local and integration.
16. The method as claimed in claim 11, wherein step of performing validation includes validating the web clients before submitting requests to a server.
17. The method as claimed in claim 11, wherein step of performing validations further includes selection from the group consisting of mandatory/ optional, type, format and length.
18. The method as claimed in claim 11, wherein step of performing validations can further allow inclusion of new custom format validations.
19. The method as claimed in claim 11, wherein the step of filtering said extracted data is carried out after checking if the filter is configured.
20. The method as claimed in claim 13, wherein step of invoking the gadgets can be performed from authorized internal or external sites based on the received request.
,TagSPECI:FIELD OF THE DISCLOSURE

The present disclosure relates to the field of web portal applications.

DEFINITIONS OF TERMS USED IN THE SPECIFICATION

The term ‘master data’ used hereinafter in this specification relates to important/critical data from number of distinct sources that needs to be loaded/displayed on the multiple rendered web pages of web portal applications.
The term ‘payload’ used hereinafter in this specification relates to the actual information that needs to be sent to a destination system.
The term ‘json payload’ used hereinafter in this specification relates to the information that needs transmitted and/or received in json format.
The term ‘xml payload’ used hereinafter in this specification relates to the information that needs transmitted and/or received in xml format.
The term ‘environment’ used hereinafter in this specification relates to a tier designated to a specific stage in a method and can be selected from the group consisting of development, production, user acceptance testing, local and integration.
The term ‘web client’ used hereinafter in this specification relates to a computer application such as a web browser that runs on a user's local computer or workstation and connects to a server as necessary.
These definitions are in addition to those expressed in the art.

BACKGROUND

A traditional web portal application allows a user to fill and/or submit a form on a portlet. On form submission, a web server receives this request from a web browser and responds to the web browser with new or relevant web page. This may result in replication of data and waste of bandwidth since same web contents of the original web page may be present in the responded web page.
Additionally, portal application performance for end-user experience is adversely affected since heavy processing is involved in the current portal applications. These applications are not portable and hence can only be deployed on respective application servers. Also, current portal applications are difficult to customize.
Further current web/portal platforms do not provide maximum inbuilt mechanisms required for end-to-end application development including master-data management, template based json/xml generation, instrumentation-enabled logger, data-access mechanisms, transaction management mechanisms, ready-to-use multiple file upload/download mechanisms, Out Of the Box (OOTB) integration with social sites, and instrumentation enabled app logger and the like.
Therefore, there is felt a need for a system that limits the aforementioned drawbacks of conventional web / portal applications.

OBJECTS

It is an object of the present disclosure to allow division of a portal page into portlets and further into fragments of portlets.
Another object of the system of the present disclosure is to provide simultaneous, asynchronous and independent rendering/refreshing of portlet/portlet fragments without interfering with other components of a web page.
Another object of the present disclosure is to provide automated template-based json/xml payload generator that allows easier development of web/portal application.
Another object of the present disclosure is to allow personalization of the web/portal applications.
Yet another object of the system of the present disclosure is to allow integration of portlets with any remote website by making the portlets available as Gadgets.
Still a further object of the system of the present disclosure is to provide a user/role based access to the portals/pages/portlets/portlet fragments, finest level of fields on portlets/portlet fragments and also for backend processes.
Other objects and advantages of the present invention will be more apparent from the following description when read in conjunction with the accompanying figures, which are not intended to limit the scope of the present disclosure.

SUMMARY

The present disclosure envisages a computer implemented system for web / portal applications.
Typically, in accordance with the present disclosure, the system for web portal applications includes a receiver adapted to receive requests from a user through a web client in the form of an initial request and subsequent requests for performing relevant actions on at least one portlet on a web portal page that comprises a plurality of individually accessible and operable portlets with/without portlet fragments.
Further, in accordance with the present disclosure, the system includes an environment switch adapted to receive an initial request from the receiver and further adapted to check, load and switch a web / portal application in an environment mode depending on the initial request.
Furthermore, in accordance with the present disclosure, the system includes a web client validator adapted to receive an initial request and subsequent requests from the receiver and further adapted to perform automated validations for each element before submitting a request to perform relevant actions on the loaded environment.
Additionally, in accordance with the present disclosure, the system includes a user entitlement checker adapted to receive an initial request and subsequent requests from the receiver and further adapted to perform user authorization check to check if a user is authorized to access pages, portlets, portlet fragments, finest level of fields or any backend processes;
Still further, in accordance with the present disclosure, the system includes a master data processor adapted to receive an initial request and subsequent requests from the receiver and further adapted to provide master data to the user node, the master data further comprises:
• a server cache adapted to receive an initial request and subsequent requests from the receiver and further adapted to store master data from external sources;
• a client cache adapted to receive subsequent requests and further adapted to receive and store master data from the server cache based on the received requests;
• a crawler and extractor adapted to receive an initial request and subsequent requests from the receiver and further adapted to crawl sequentially through the client cache and the server cache to extract data requested through the received requests; and
• a filter adapted to receive an initial request and subsequent requests from the receiver and the extracted data from the crawler and extractor, and further adapted to filter the extracted data based on pre-determined filters and the received requests to obtain master data.; and
Further, the system includes a portlet fragment retriever adapted to receive the initial request and the subsequent requests from the receiver and further adapted to render/refresh based on the received request, a portlet and/or a fragments of portlets, without impacting other portlets or fragments of portlets on the page.
Furthermore, the system includes an automated template-based json/xml payload generator adapted to receive the initial request and the subsequent requests to create json/xml based payloads, and further adapted to send auto-generated json/xml messages to the portlet fragment receiver and/or the gadget retriever and/or external systems.
Additionally, the system includes a gadget retriever adapted to receive subsequent requests from the receiver and further adapted to invoke the portlets and include them as gadgets on remote web portal pages on the user node.
Still further, in accordance with the present disclosure, the system includes a display adapted to receive responses from the validator, the master data processor, the portlet fragment retriever and the gadget retriever and further adapted to display the responses on the user node.
Furthermore, the environment mode is selected from the group consisting of development, production, user acceptance testing, local and integration.
Still further, in accordance with the present disclosure, the web client validator performs validations on the web clients before submitting requests to a server and is further adapted to include new custom format validations.
Additionally, the validations are selected from the group consisting of mandatory/optional, type, format and length.
Further, in accordance with the present disclosure, the filter is adapted to check filter configuration in order to filter the extracted data.
Furthermore, the gadgets that can be invoked by the system are remote portlets that can be invoked from authorized internal or external sites based on the received request.
In accordance with the present invention, there is provided a method for web portal applications, the computer implemented method comprises the following steps:
• receiving requests from a user through a web client in the form of an initial request and subsequent requests for performing relevant actions on at least one portlet with/without portlet fragments on a web portal page that comprises a plurality of individually accessible and operable portlets with/without portlet fragments;
• receiving an initial request from the receiver and checking, loading and switching a web portal application in an environment mode depending on the initial request;
• performing automated validations for each element upon the receipt of a request to perform relevant actions on the loaded environment;
• performing user authorization check based on an initial request and subsequent requests to check if a user is authorized to access pages, portlets and/or portlet fragments, finest level of fields/elements, backend processes;
• providing master data to the user node based on the received initial request and subsequent requests, the step of providing master data further includes:
o storing master data from respective sources in a server cache based on the received initial request and subsequent requests;
o storing master data from the server cache onto a client cache based on the received subsequent requests;
o crawling sequentially through the client cache and the server cache and extracting data from the client cache and server cache based on an initial request and subsequent requests received through the receiver; and
o checking if the filter is configured and obtaining master data by filtering the extracted data based on an initial request and the subsequent requests received from the receiver.; and
• rendering/refreshing a portlet and/or fragments of portlets without impacting other portlets or fragments of portlets on the page based on the received initial request and subsequent requests from the receiver and the filtered master data.
Additionally, in accordance with the present disclosure, the system includes step of automatically creating json/xml based payloads and also includes step of sending the auto-generated json/xml messages to the portlet fragment receiver and/or the gadget retriever and/or external systems.
Typically, in accordance with the present disclosure, the method further includes step of invoking the portlets and including them as gadgets on remote web portal pages on the user node.
Further, in accordance with the present disclosure, the method also includes the step of displaying the responses received from the validator, the master data processor, the portlet fragment retriever and the gadget retriever on the user node.
Furthermore, the step of loading an environment mode further includes the step of selecting the environment from the group consisting of development, production, user acceptance testing, local and integration.
Still further, the step of performing validation includes validating the web clients before submitting requests to a server.
Additionally, the step of validation also includes selection from the group consisting of mandatory/optional, type, format and length.
Further, the step of performing validations can also allow inclusion of new custom format validations.
Furthermore, the step of filtering the extracted data is carried out after checking if the filter is configured.
Still further, the step of invoking the gadgets can be performed from authorized internal or external sites based on the received request.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

The computer implemented system and method for web portal applications of the present disclosure will now be described with reference to the non-limiting accompanying drawings, in which:
FIGURE 1 illustrates the schematic of web portal application system in accordance with an embodiment of the present disclosure.
FIGURE 2 illustrates the system flow for automatic loading of configuration based on an environment-switch.
FIGURE 3 illustrates the system flow for validating user entered data on a web client.
FIGURE 4 illustrates the system flow for checking user entitlement.
FIGURE 5 illustrates the system flow for extraction and downloading of Master Data.
FIGURE 6 illustrates the system flow in one embodiment for auto-population of multiple dependent master data controls
FIGURE 7 illustrates the system flow for retrieving a portlet fragment.
FIGURE 8 illustrates the system flow for invoking remote portlets in remote website.
FIGURE 9 illustrates the system flow for automated template-based payload generation.

DETAILED DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The computer implemented system and method for web portal applications will now be described in detail with reference to the accompanying drawings. The preferred embodiment does not limit the scope and ambit of the disclosure. The description provided is purely by way of example and illustration.
The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
Web portals aggregate contents on a single location that is network addressable. Components of a portal page typically include a portal header, a page header, a page body, portlets and portal footer. Each portlet in a portal occupies a portion of the portal page where the portlet displays relevant content. In the system of the present disclosure, the portlets are further divided into portlet fragments. When a new page is loaded with the help of the system of the present disclosure, only the page body gets fetched form a server on every page hit, whereas the portal header, page header and the portal footer remain constant till the page window is closed. Similarly, in case of portlets, only the respective portlet on which the actions are performed gets refreshed from the server, everything else remains unchanged. Accordingly, if an action is performed on a portlet fragment, only respective portlet fragment is refreshed from the server and the rest of the portal and portlets remains unchanged.
The system of the present disclosure allows asynchronous download of dependent scripts. It also supports various browsers by using browser specific handling. The system also provides inbuilt functions for automated, dynamic rendering of grid-table, pop-ups, drop-downs, radio buttons, check-boxes and dependent controls for multiple complex master data. A unique transaction ID is also provided for each request and a log is maintained for the same to allow traceability of the transactions across all tiers.
The system of the present disclosure also provides request based session support wherein the system manages session support for each request based only on the configuration. This is useful when certain pages/portlets/requests require user to be logged-in whereas certain pages/portlets/requests may be available to the users without logging-in. Access to social networking sites including Facebook, Google+, LinkedIn and the like can be integrated with the system of the present disclosure and can be enabled/disabled by configuration. The system makes use of a unique error token that is displayed on the client and the maintained logs in order to allow tracking and troubleshooting of error.
Referring to the accompanying drawings, FIGURE 1 illustrates the schematic of web portal application system 100. The system 100 of the present disclosure includes a receiver 102 that receives requests from a user through a web client for performing relevant actions on at least one portlet with/without portlet fragments on a web portal page that comprises a plurality of individually accessible and operable portlets with/without portlet fragments. These requests are then passed on the respective modules in order to access and/or retrieve required data. The system of the present disclosure includes an environment switch 104 that checks, launches and switches the web portal application in the required environment mode at the start of the application. These environment modes include but are not limited to DEV, PROD and UAT and are launched without replacing any environment specific configuration during application rebuild/redeploy. At the start, an environment switch checker 106 based on the request received from the receiver 102, checks if an environment switch is present on a physical environment, if the switch is present, respective environment specific configuration is loaded with the help of an environment loader 108 on a user node. If the environment switch is not found on the physical environment, the web portal application is launched on safe (DEV) mode. All generic application configurations that are common across all environments are defined in generic configuration, whereas the environment specific application configurations are maintained separately. Once appropriate environment is loaded, the system 100 automatically starts functioning as per the environment.
User authorization check is performed by a user entitlement checker 114. The user entitlement checker 114 enables user/role specific entitlement of a particular request that is received from the receiver 102. This check is performed while rendering a page, portlet and any smallest element within the portlet (i.e. a portlet fragment, fields etc.). It also provides checks in case of server-side processing of requests to check if user is trying to directly launch an unauthorized feature request. Once the entitlements checks are complete, a resultant view is rendered to the client. The user can then perform relevant action and can further perform actions on the view such as requests for a portal, page, portlet or a portlet fragment through the web client.
When any request is received from the user, it is first validated by a web client validator 112 on the client side. If it is an initial request for loading the environment, the web client validator 112 after validation passes it for loading the appropriate environment based on the environment switch 104. Before any further user's actions/requests are processed by the system 100, validations are carried out by the web-client validator 112. The web client validator 112 is an automated field-level client validator that performs automated standard validations, based on the request received from the receiver 102, for each element before submitting it to a server. It also has the provision to include new custom format validations. When the web client is validated the system can process further requests received from the receiver 102. If the web client is not validated, the system provides failure messages to the user which is displayed on a display 144.
When a web client request is received by the system, the automated template-based json/xml payload generator 146 may be used for creating json/xml based payloads to be sent to services for further processing.
When a web client request is received by the system 100 through the receiver 102 for accessing a feature within a portal, page, portlet or a portlet fragment, the system 100 first validates the user, then performs entitlement check and determines the resultant View to be rendered to the user. If the View requires master data, then a master-data processor 116 checks for the availability of the master data on the client. If the data is not available, the master data processor 116 obtains the required data.
The master data processor 116 retrieves data payload that needs to be sent from the server to the client while rending a web page. It can dynamically load master data from any number of discrete sources/platforms. Once the master data is loaded, it is maintained in a server cache 122. The data from server cache 122 is distinguished and loaded in a client cache 120. The data that is retrieved by master data processor 116 can be downloaded at a browser so as to prevent repetitive fetching of master data every time the user makes a request. When the user requests access or some information from a portal, page or portlet which contains master-data, a client cache 120 is first checked for the master data by the client. If the required data is not found in the client cache 120, a crawler and extractor 118 crawls through the data from a server cache 122 which stores in-memory or external cache. This server cache 122 is adapted to identify and store the master data from external sources. So, when the data requested by the user is found in the server cache 122, it is extracted by the crawler and extractor 118. Based on runtime parameters including attributes of the user and the like, the extracted data is filtered by a filter 124 in case a dynamic filter is configured. This filtering method allows download of minimal required data instead of the entire master data thus, reducing bandwidth usage. This filtered data is then downloaded and stored in the client cache 120 for further processing or displayed on the display 144 depending on the request from the receiver 102.
A portlet fragment retriever 126 allows refreshing of only a fragment of the portlet without impacting the entire portlet and page. A response of portlet fragment retriever 126 is displayed on a display 144, the response can be a view or data attributes based on the user’s request received from the receiver 102. When the user issues a request to the server through the receiver 102 for rendering a portlet fragment, the request is first parsed by the parser 128. An identifier 130 then identifies the related components including data handler and business processor components for the request. Based on the identified components a processor 132 processes the request and provides a result status. Based on the result status a view component is determined by a determinator 136, if there is an error in determining the view component an exception is generated by an exception handler 134 and corresponding error message is displayed on the display 144. If the view component is successfully determined it is displayed on the display 144.
The system 100 of the present disclosure introduces gadgets which are customizable remote portlets that can be included on remote websites. The gadgets can be invoked from authorized internal or external sites by the user with the help of a gadget retriever 138. It includes an invoker 140 that allows the user to invoke a gadget. An interceptor 142 then intercepts the user request received from the receiver 102 in order to check if the request of invoking a gadget is from a remote website. The gadget can also be rendered in case of a local request. If the request is from the remote website, all future requests from the gadget are treated as remote calls. The request is then processed by the portlet fragment retriever 126 and the requested remote portlet/gadget is rendered to the client on the display 144.
Referring to the accompanying drawings, FIGURE 2 illustrates the system flow for automatic loading of configuration based on environment-switch. When the web portal application is started, the first step performed by the system of the present disclosure involves checking the physical presence of an environment switch 200. If the environment switch is not found, the system starts in a safe mode and sets the environment switch to default safe mode 202. If the environment switch is found, the system automatically loads a configuration based on the environment switch 204 and the web portal application automatically starts functioning as per the selected environment 206.
Referring to the accompanying drawings, FIGURE 3 illustrates the system flow for validating a web client. When a user clicks an actionable button on the screen from the web client, a web client validator is invoked 300. A form object is then parsed 302 based on user selection/input. A check is performed for custom attributes of every element of this form object, where the custom attributes include type of the object, mandatory fields, standard formats for various fields, captions, maximum length and the like 304. Based on the check performed on each element of the form object, the data in each element is validated as per the specifications in its custom attributes 306. If the data is not valid, the element is termed to be invalid and in added in collection of invalid elements and appropriate failure message is displayed 308. If an element data is valid same check is performed on the next element 310. If invalid elements are present, a failure message is displayed to the user 314.
Referring to the accompanying drawings, FIGURE 4 illustrates the system flow for checking user entitlement. When a user issues a request for a portal, page, portlet or a portlet fragment through a web client, a check is performed to ensure that the user is entitled to the request 400. If the user is not entitled/ authorized to carry out the requested action, an entitlement failure exception is generated 402 and a user-friendly entitlement failure message is displayed in the placeholder of the requested page/portlet/fragment 404. When the user performs an action on a resultant View, web client validation is performed to check if the data entered by the user on the web client is valid. Once the web client is validated, the request is processed by the system. The request is parsed 406 if the user is entitled to the request. From the parsed request, data handling and business processing components are identified 408. The request is then process 410. If an exception occurs during processing, the exception is handled 412 and a standard error message is displayed 414. If the request is processed successfully, a view component is determined based on the outcome of processing 416. Any failure occurred in this step is handled 412 and the user receives the standard error message which is displayed in the error placeholder in the requested page/portlet/fragment 414. Once the view component is successfully determined, each view component is parsed to check for any entitlement features 418. For each entitlement feature a check is performed to confirm if the user is entitled to the feature in the view component 420. If the check is unsuccessful, the feature in question in the view component is not rendered 422, else it is rendered 424. A view component is then set in the response 426 and the response is provided to the web client which sets it on the display in the respective placeholder of the requested portal/page/portlet/fragment 428 for the user.
Referring to the accompanying drawings, FIGURE 5 illustrates the system flow for extraction and downloading of master data. The system first checks for master data in a client cache 502 when a user with the help of a web client requests a portal/page/portlet that needs to use some master data of a complex structure 500. If the master data is found in the client cache, it is populated on the page requested by the user 504. If the master data is not found in the client cache, configuration for the client side master data composition is checked 506. For each master data object in the composition, it is checked if a master data object exists in server cache 508. The master data object is extracted from the server cache 510 if it exists in the server cache. Once the object is extracted, it is checked whether a dynamic filter is configured 512. The filter implementation allows for filtering of the master data based on runtime parameters and only the minimal necessary data is downloaded instead of the entire master data. If the filter is configured, the filter implementation is invoked 514 to download minimal data for creation of client side master data composition. If the filter is not configured, the client side master composition is created with the entire master data 516. This master data is then downloaded at the client 518 and then referred to the client cache to populate on the requested page 504. If the master data object does not exist in server cache, a loader is identified for the master data object 520. It is checked if a master data loader for respective object is found 522. If loader is not found, next master data object is considered and its existence in server cache is checked 508. If the master data loader is found, respective master data loader is invoked in order to load master data from respective source 524. The data is then converted to master data object structure in to enable complex many-to-many dependent masters and multilingual attributes 526. The converted master data is then cached in the server cache. This process is repeated for all the master data objects in the composition. Once the master data is cached in the server cache 528, the master data object is then extracted 510 and then further processed.
Referring to the accompanying drawings, FIGURE 6 illustrates the system flow in one embodiment for auto-population of multiple dependent master data controls. When a user requests for a page containing multiple dependent master data selection controls 700, the master data extraction and downloading process as explained in the flow diagram of FIGURE 5 is carried out 702. In this example four master data controls viz. Ctrl-1, Ctrl-2, Ctrl-3 and Ctrl-4 are considered. A web client displays the page containing these multiple dependent master data controls such that Ctrl-1 and Ctrl-2 are independent and prepopulated, Ctrl-3 depends on selected values in Ctrl-1 and/or Ctrl-2 and, Ctrl-4 depends on the selected values in Ctrl-3 704. Depending on the type of control (for e.g. dropdown, radiobtn, textbox, checkbox etc.) html is generated for every control 706. Ctrl-1 and Ctrl-2 are pre-populated and Ctrl-3 and Ctrl-4 are empty 708. When the user selects/changes a value in Ctrl-1 or Ctrl-2 710 and 712, the selected values of Ctrl-1/ Ctrl-2 along with the respective position of the dependent column/s is passed in the Ctrl-3 data structure 714. The process then iterates through the master-data objects for Ctrl-3 and filters for the selected dependent column values related to Ctrl-1/ Ctrl-2 716. Once the filtered values are obtained, Ctrl-3 is emptied and then populated with these values in a defined sort order 718. When user selects/changes the value in Ctrl-3 720, the selected value is passed in Ctrl-4 along with the respective position of the dependent column 722. The process then iterates through the master-data objects for Ctrl-4 and filters for the selected dependent column values related to Ctrl-3 724. Ctrl-4 is then emptied and populated with the obtained filtered value in defined sort order 726.
Referring to the accompanying drawings, FIGURE 7 illustrates the system flow for retrieving a portlet fragment. When a user through a web client requests a server to render a portlet fragment 800, the request is first parsed 802. Data handler and business processor components are then identified for the parsed request 804. The request is then processed and the result status is determined 806. A view component is then determined based on the status of the request processing 812. In case of any exception or failure in processing the request, an exception handler handles the exception 808 and the user receives a standard error message which is displayed in the error placeholder in the portlet 810. On success of the request, the view component is set in the response 814. The web client receives this response and sets it in the portlet fragment placeholder within a portlet 816 to allow user to view the portlet fragment and perform actions.
Referring to the accompanying drawings, FIGURE 8 illustrates the system flow for invoking remote portlets in remote website. Remote portlets in the system of the present disclosure are termed as gadgets. These gadgets are customizable remote portlets that can be included on remote websites and can be invoked from authorized internal or external sites by the user. When a user wants to use a gadget, a web client of the remote website invokes an embedded client-code snippet 900. This request is intercepted 902 and parsed 904. A check is performed to confirm if the request is from a remote website 906. If the request is not from remote website the process is ended 908 else a remote flag is set 910. Data handler and business processor components are then identified for the request 912. The request is then processed 914 and the result status is determined. A view component is then determined based on the status of the request processing 918. In case of any exception or failure in processing the request, an exception handler handles the exception and sets error message in the response 916. The remote client then receives a standard error message which is displayed on the remote website as per the requirement 928. When, the request is successful, the view component is set in the response 920 and the web client receives the response and sets it in the placeholder in the portlet 922. A check is then performed to check is the remote flag is set 924, if it is set, all the further requests from the gadget are considered as remote calls 926 else the process ends 930.
Referring to the accompanying drawings, FIGURE 9 illustrates the system flow for automated template-based payload generation. When a web client request is received by the system, the automated template-based json/xml payload generator may be used for creating json/xml based payloads. Any complex structure with any level of nesting/hierarchy and any level of repeatability of elements can be implemented with the help of template-based payload generation. In this process, input provided by a data handler includes data hashmap and json/xml template identifier 1000/2000. Based on the identifier a predefined json/xml template is obtained 1002/2002 and data hashmap is looped 1004/2004 to check if a data element is found in the template 1006/2006. The data element is skipped if it is not found else the data element is set in json/xml payload as per its type or position in the template 1008/2008. A json/xml payload is then returned 1010/2010.

TECHNICAL ADVANCEMENTS

The technical advancements of the computer implemented system and method for web /portal applications as envisaged by the present disclosure include the realization of:
• a system that allows division of a portal page into portlets and further into fragments of portlets;
• a system that provides simultaneous, asynchronous and independent rendering/refreshing of portlet/portlet fragments without interfering with other components of a web page;
• a system that provides a master data renderer and ready-to-use client functions for managing dependent master data;
• a system that provides ready-to-use automated template-based json/xml payload generator that allows easier development of web/portal applications.
• a system that allows personalization of web/portal applications;
• a system that allows integration of portlets with any remote website by making the portlets available as Gadgets; and
• a system that provides a user/role based access to the portals/pages/portlets/portlet fragments, finest level of fields on the portlets/portlet fragments and also for backend processes;
• a system that provides ready-to-use client validator; and
• a system that provides inbuilt switch-based environment configuration loader.
While considerable emphasis has been placed herein on the particular features of this disclosure, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiment without departing from the principles of the disclosure. These and other modifications in the nature of the disclosure or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.