Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Algorithm for facilitating reliable dynamic content in aggregated markup

IP.com Disclosure Number: IPCOM000126797D
Original Publication Date: 2005-Aug-02
Included in the Prior Art Database: 2005-Aug-02
Document File: 7 page(s) / 83K

Publishing Venue

IBM

Abstract

How to ensure your page content survives aggregration in a portal world.

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

Page 1 of 7

Algorithm for facilitating reliable dynamic content in aggregated markup

Sophisticated web applications often amalgamate page content from multiple sources. With aggregated content, such as that generated by portal based software (ref. JSR-168* and similar) inherent namespace-related problems arise from the very fact that many independent sources are ultimately merged into a single entity. Problems are particularly likely to arise when consituent pages aim to provide non-static content. For instance, portal-based software can readily amalgamate page content that consists solely of HTML, but it cannot readily amalgamate page content that consists of both HTML and Javascript*. As a result such amalgamated pages generally cannot support "dynamic" HTML, that is, pages that interact with a user.

    There are several dimensions to this problem, for example, since the pages being amalgamated do not know about each other, they may declare variables that have the same name thus leading to runtime errors. Or, the pages may attempt to use parts of the Javascript DOM which are not available when the pages get amalgamated, for example, they may use the "load" event of the page' <body> tag. The lack of interactivity that results severely limits the usability and usefulness of portal and other similar amalgamated pages. For example, it is difficult (or impossible) to provide such basic features as "mouse-over" effects (e.g., when a user moves the mouse over some part of the page, the object changes color or shape to inform the user that they are over a part of the page which can be clicked).

    The scheme described here allows any page being amalgamated into a portal or other such page to use Javascript in such a way that said script will always work once the page is merged together with other pages (even pages that do not use this scheme). To more thoroughly understand the issue, a brief description of an HTML page is needed. An HTML page consists of a head and a body, demarcated with the tags <head> and <body>, for example:

    As suggested by the names of the tags, the head area contains general directives, includes, style declarations (non visual information) and the body area contains the HTML tags that result in something visual being displayed (e.g., text, images, media, etc.). Javascript is added to the page primarily as either "in-line" Javascript declarations/statements or as "event-handlers". (Script may also be included indirectly via libraries, but it behaves the same as in-line script or event-handlers.

In-line script executes as soon as the HTML renderer encounters it. Script in an event-handler is executed as a result of a user action (for example, moving the mouse, typing) or a system-defined action (for example, as a timer).

<head> head information </head> <body> body information </body>

For example:

Page 2 of 7

<body>

<script> var i = 1; function countClicks() {

i = i + 1; window.status = "Number of times you clicked this button: " + i;...