Browse Prior Art Database

Method for Keeping Track of Browser Screen in Web 2.0 Application Toolkit

IP.com Disclosure Number: IPCOM000202115D
Publication Date: 2010-Dec-04
Document File: 4 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method which improves Web 2.0 client toolkits on the client as well as the server frameworks such that the developer can build the Web applications that are based in them to treat each browser screen independently, without having to write any non-application specific code. The method incorporates the use of screen IDs, an exchange protocol, an internal variable to assist with screen ID storage, and an Application Programming Interface (API) in the server framework.

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

Page 01 of 4

Method for Keeping Track of Browser Screen in Web 2.0 Application Toolkit

In a Web application, a session is often used to keep track of the browser interactions and the Web application running in Web container. Different users using different computers have different sessions. For example: a Java* EE application calls the getSession() method of the HttpServletRequest to retrieve the Hypertext Transfer Protocol (HTTP) session object. Since the HTTP session is different for different users using different computers, the returned value from the getSession() method only contains the interaction information between application and one user. This enables the application to be coded in such a way that it does not need to consider how other users are using the application.

However, with an ever-increasing trend toward multitasking, many users open multiple browser windows or tabs on the same computer; each connects to the same Web application but the user needs them to behave independently. For example, a user might want to open two browser tabs to manage two different accounts that have different user IDs and passwords. Here, the browser window or tab is referred to as a browser screen.

Some browsers are designed to share the session among different browser screens. This makes it difficult for the Web application to be coded in such a way that the applications running in different browser screens are independent of one another.

The disclosed solution is a method to improve Web 2.0 client toolkits on the client as well as the server framework. As a result, the developer can build the Web applications that are based in them to treat each browser screen independently, without having to write any non-application specific code.

The components of the solution include:
• Screen ID: an ID to identify the browser screen
• Protocol between the client and the server to exchange the screen ID for all the requests and responses

• Internal variable to store the screen ID in the Web 2.0 client toolkit; the toolkit can expose it if desired

• An Application Programming Interface (API) in the server framework for the application developer to retrieve the data specific to the browser screen.

The method implements these components to allow the application developer to develop applications that treat browser screens independently from one another. The process in a typical embodiment is:

1. Creating/Using Screen ID


Normally, the user opens a new browser screen and connects it to the Web application by entering a direct URL in the browser's address field. This causes an HTTP request to be sent to the Web server.

1


Page 02 of 4

When the server framework, such as servlet Web container, receives the request, it verifies whether the request contains a parameter containing the screen ID. The parameter name can be anything that fits the naming convention of the Web 2.0 client toolkit. The parameter name can be configured through an administration mechanism.

...