Browse Prior Art Database

A method for dynamically loading and updating portlets

IP.com Disclosure Number: IPCOM000125710D
Original Publication Date: 2005-Jun-14
Included in the Prior Art Database: 2005-Jun-14
Document File: 2 page(s) / 61K

Publishing Venue

IBM

Abstract

The key principle behind how portal servers generate their aggregated content today is that each request to the portal server rebuilds the portal desktop (as represented in HTML in a user's browser) and yields a complete HTML document composed of the markup yielded by each portlet. In essence this means that to complete the portal HTML markup, each portlet on the page needs to return its fragment of markup before the page can be returned to the user. This then means that the page can only be returned as fast as the slowest portlet to return its markup. It is difficult for a user to start work with another portlet whilst other slower portlets are loading. Also, this creates the problem with dynamic data that it is necessary to refresh the whole of the portal desktop in order to update the content of the other portlets.

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

Page 1 of 2

A method for dynamically loading and updating portlets

The key principle behind how portal servers generate their aggregated content today is that each request to the portal server rebuilds the portal desktop (as represented in HTML in a user's browser) and yields a complete HTML document composed of the markup yielded by each portlet. In essence this means that to complete the portal

  HTML markup, each portlet on the page needs to return its fragment of markup before the page can be returned to the user. This then means that the page can only be returned as fast as the slowest portlet to return its markup. It is difficult for a user to start work with another portlet whilst other slower portlets are loading. Also, this creates the problem with dynamic data that it is necessary to refresh the whole of the portal desktop in order to update the content of the other portlets.

  Currently, a solution for decoupling portal aggregation from the portal server (and hence return the page promptly) is to use an HTML IFRAME to contain the content for that portlet. However, this means that effectively the application has left the boundaries of the portal since an IFRAME is logically a new browser window and has its own URL

(outside the main portal) and such like. The

IFRAME can therefore load and be forced to refresh independently of the portal server but theoretically, the portal has now lost control of that portlet. Also, refreshing the whole IFRAME can be inefficient if there is a large amount of content to be returned each time.

    The proposal detailed here consists of a visually unobtrusive "back channel" into the client browser defined in markup whereby the portal page aggregation can return before the markup for each portlet has been returned. As the portlet markup is generated, it returns via the backchannel and is integrated into the markup of the portal desktop HTML document. This can be used both on a per-page request basis (i.e. simply to draw all the portlets) and also to incrementally update a portlet fragment within a browser DOM tree. In this way the markup is still rendered in the same logical HTML document DOM as the portal aggregation framework and widgets and therefore is still bound to the portal context. The back channel can be left open such that the client can receive periodic updates (e.g. to follow a news feed) without having to refresh the whole page or sub-frame. All of this can be achieved without a third-party plug-in in the browser since it is accomplished purely using markup and onboard scripting.

    In an example, HTML rendering of a portal desktop for a page request is sent to the portal server. The user's desktop consists of portlets A, B and C. The portal invokes a doView() method on each of the portlet instances for the given user session. Each doView() call is run in a logical child thread and asynchronously returns a handle to the markup output stream that each portlet will generate. The portal then builds an HT...