Browse Prior Art Database

Method for detecting successful initialization and activation of dynamically loaded Headless Applet in Web 2.0 applications

IP.com Disclosure Number: IPCOM000229417D
Publication Date: 2013-Jul-28
Document File: 3 page(s) / 20K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for enabling an Applet and a Web 2.0 application to exchange messages to reach an agreement for when the Applet is properly loaded, enabling the Web 2.0 application to call its Application Protocol Interface (API).

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

Page 01 of 3

Method for detecting successful initialization and activation of dynamically loaded Headless Applet in Web 2.0


2.0 applications

applications

Dynamically loaded Headless Applets are those applets whose APPLET tags are dynamically added to the Document Object Model (DOM) tree of an application based on a preference value. A Headless Applet does not have a User Interface and has

additional security restrictions. Web 2.0 applications that depend on the proper initialization of a dynamically loaded Applet component need to be able to determine the appropriate time to begin making calls to the Applets. Many variables make this process challenging. From the browser side, different browsers tend to load the Applet faster than others do. Browsers also handle failures when trying to invoke a function in an Applet before it is initialized; some browsers generate errors while other browsers simply return a null or empty value.

In an example problem scenario, a Headless Applet is required to retrieve State Information from the File System upon initialization. Because the Applet needs to access File Information, users are require to accept the Security Certificate of the

Applet, a step that at times depends on the user pressing the Accept button. Often, even if the user accepts the security certificates, it is not guaranteed that the Applet has timely access to file information. For this reason, the Initialization code is moved execute after the Applet completed the started phase. The new required step performs the reading of configuration files after the Applet is started. This additional step not only requires the Applet to be installed and started, but also initialized before being able to accept requests from the Web 2.0 Application.

A method is needed to determine when a dynamic Applet is started, thus enabling a Web 2.0 application to call functions from it. Most solutions treat Applet as a separate entity of the Web 2.0 application or assume the Applet is the source of the requests.

This approach is a method for enabling an Applet and a Web 2.0 application to exchange messages to reach an agreement for when the Applet is properly loaded, enabling the Web 2.0 application to call its Application Protocol Interface (API).

The solution is implemented using a Java* Applet and a Web 2.0 application with a Dojo Toolkit (Dojo Publish/Subscribe functionality), Hypertext Markup Language (HTML), and JavaScript**. The steps for implementation in a preferred embodiment follow.

Step 1: Install Applet Dynamically

The purpose of Step 1 is to follow best practices for loading an applet dynamically. The steps followed here are no different from the already available solutions.

Step 2: Applet Start External & Internal Notification Sequence

The purpose of this step is to reach an agreement between the Applet and the Web 2.0

Application that the Applet has completed its START sequence. This step addresses

the need to have the Applet available to accept func...