Method for detecting successful initialization and activation of dynamically loaded Headless Applet in Web 2.0 applications
Publication Date: 2013-Jul-28
The IP.com Prior Art Database
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).
Page 01 of 3
Method for detecting successful initialization and activation of dynamically loaded Headless Applet in Web 2.0
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).
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...