Browse Prior Art Database

A Multi-Browser Framework For Portal Solutions

IP.com Disclosure Number: IPCOM000022113D
Original Publication Date: 2004-Feb-25
Included in the Prior Art Database: 2004-Feb-25
Document File: 3 page(s) / 97K

Publishing Venue

IBM

Abstract

This article describes an application aimed at reducing the level of screen refreshing when accessing web sites or portals. With conventional browser technology the screen is refreshed each time a User initiates an HTTP transaction. This refresh occurs even if there are no actual changes to the content. Existing methods of alleviating this problem are based on the use of script technologies such as Java applets. The system described in this article reduces the level of screen refreshing without the need to alter the actual web site functionality.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 3

A Multi-Browser Framework For Portal Solutions

Portal solutions generally use standard web and browser technologies for interaction with the user. Whilst there are numerous advantages to this approach (e.g. standardisation of protocols, thin client, simplicity and familiarity of browser interface, etc) there are also a number of disadvantages. In particular:
1. When the user initiates a web transaction from one portlet the whole screen is refreshed. This is both distracting and slow for the user.
2. When multiple portlets are configured on a portal page, the speed of refresh is governed by the speed of the slowest portlet. These problems are currently addressed using complex, and often bespoke, solutions. For example, Portlets may be designed to use web services, such that, the browser refreshes whilst the service is still running in the background. Such an approach requires either the user to initiate a further refresh to check whether the service has completed or some form of Applet polling of the web service. The disadvantages of this approach are:
1. Additional coding and architectural effort is required to define the web services.
2. Manual refresh of the browser requires user intervention and may be requested before the service has completed its actions such that further manual refreshes must be completed.
3. Automated refresh using Applet polling, requires an increased number of transactions with associated increase in network traffic. In addition the refresh speed is governed by the frequency of polling as opposed to the speed of the service completing its actions.

    The proposed solution to this problem is to implement a new extended browser. The extended browser would be implemented as a single application in a conventional high level language such as C++, Java* or Delphi. The extended browser would be installed on a client machine and be used in place of a conventional browser such as Microsoft Internet Explorer*, Netscape Navigator or Mozilla.

The functionality of the extended browser is best described by considering:
1. The initial rendering of a web page by the browser.
2. The re-rendering of the web page, or a part of the web page, in response to an event such as a user action.

Initial rendering of a web page

    On starting the extended browser, the required web page (specified by either the initiating or default URL) retrieved using the same mechanisms as those used by existing browsers. However, before the web page is rendered the extended browser parses the returned HTML/XML to identify discrete sub components that may be independently rendered. For example, in cases where the returned HTML has been generated by a Portal Server the extended browser will identify the HTML/XML representing individual Portlets. One simple manner in which this can be achieved is to amend the markup language schema to include specific tags/attributes that identify individual components within a web page. Even without such an amendment it is poss...