- Intended Audience
- Deployment Assumptions
- How the Gateway Works
- Concepts of the Rewriter
- Adding and Removing Rewriter Rules
- Methodology for Rule Extraction
- Out-Of-Box Rule Set
- Rewriting HTML Attributes
- Rewriting FORM Tag Input
- Rewriting JavaScript Content
- Rewriting Applet Parameters
- Rewriting Cascading Style Sheets
- Rewriting XML
- Performance
- Order Importance
- CASE Studies: How to Configure the Gateway to Rewrite a Web-Based JavaScript Navigation Bar
- Third Party Application Cookbooks
- Exchange
- How to Get Hot Patches
- Glossary
- Acknowledgements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Rewriting Applet Parameters
As with dynamic web applications created using JavaServer Pages technology, Perl, or Servlets, it is good practice not to hard code variables or URL references in Java™ applets. One mechanism to provide the applet with the location to resources or values required for the applet to run is to use applet parameters that appear as a part of the APPLET or OBJECT element using PARAM tags.
The APPLET and OBJECT tags have two attributes related to Java applets that are rewritten out-of-box. The first attribute, ARCHIVE, contains a location to a Java JAR archive. The second, CODEBASE, is used in conjunction with the CODE attribute to determine where the executable Java bytecode resides.
The CODEBASE attribute is also used when the Java getCodeBase() method is called from the applet.
NOTE
If an HTML BASE tag is included in the page, then the APPLET or OBJECT tag must contain a CODEBASE attribute. Otherwise, the applet may not load correctly because the BASE tag will be commented out after passing through the gateway. The executable Java code will attempt to be fetched using the Referrer header, which probably will not work. The SP4 Hot Patch 1 release explicitly adds a CODEBASE attribute to the APPLET tag if one does not exist and if a BASE tag exists in the HEAD element of the document.
The applet parameters can be rewritten using rules similar in syntax to FORM data. The rules allow wildcards so that patterns can be appropriately matched. The general syntax for a rule added to the Rewrite Form Input Tags List section of the gateway profile contains at least three entries:
Page or object identifier
Unlike when writing FORM data, this entry includes only the prepended path information to the page containing the APPLET or OBJECT tag.
The URL http://www.iplanet.com/applets/welcome.html page identifier would be: welcome.html
Class name, including its extension
This is the value of the CODE attribute, as in the following example:
<APPLET CODEBASE="http://www.iplanet.com/applets/" CODE="myClass.class">
Parameter name
This is the name of the PARAM tag given using the NAME attribute, as in the following example:
<PARAM NAME="headergraphic" value="/applets/images/banner.gif">
A URL pattern if the right side of the value attribute assignment is not a raw URL, as in the following example:
<PARAM NAME="headergraphic" value="98234|/applets/images/banner.gif">
The following is an example of an APPLET tag with supporting PARAM values:
<HTML> <BODY> <APPLET CODEBASE="http://www.iplanet.com/applets/" CODE="hello.class"> <PARAM NAME="leftImg" value="/images/leftImg.gif"> <PARAM NAME="rightImg" value="/images/rightImg.gif"> </APPLET> </BODY> </HTML>
If the page was accessed from http://www.iplanet.com/welcome.html, then the two rules to add to the Rewrite Applet/Object Parameter Values List would be:
welcome.html hello.class leftImg welcome.html hello.class rightImg
These rules will handle data that contains separators and URLs, following the same guidelines for wildcards in the URL pattern described in "Rewriting FORM Tag Input" on page 33.
Best Practices—Java Programming for Use Through the Gateway
You should use the following best practices:
Always use a CODEBASE attribute with an APPLET or OBJECT tag.
Use prepended path information for PARAM tag values that contain URLs.
The following is an example of what to avoid:
<HTML> <BODY> <APPLET CODEBASE="http://www.iplanet.com/applets" CODE="hello.class"> <PARAM NAME="headergraphic" value="images/banner.gif"> </APPLET> </BODY> </HTML>
Do not add a CODE rule to the Rewrite HTML Attributes section of the gateway profile.
This results in the applet not loading properly because the browser will not be able to find the Java byte code.
Do not make network connections to hard-coded URLs.
Instead, they should be passed through applet parameters.
The following is an example of what to avoid:
URLConnection myConn = (new URL('http://www.iplanet.com')).openConnection();Do not allow users to specify their own URLs in the applet user interface.
If this is required for the application to function, then you should consider running it using the netlet, instead of accessing it directly through the gateway component.
Use PARAM names when specifying rewriter rules to avoid unintentionally rewriting other APPLET PARAM values.
You should avoid using rules that look like: /path * *
Define the APPLET or OBJECT opening tag on a single line.
If not, you risk the PARAM values not being rewritten (for more information, refer to Sun BugID 4647955). The following is an example of what to avoid:
<APPLET code=foo.class codebase="/foo/foo2"> <PARAM NAME=url VALUE="/somedir/some.html"> </APPLET>
NOTE
This case can be handled in the SP4 Hot Patch 1 release by using a new gateway profile section that addresses fractured HTML. However, this type of configuration change should be avoided unless it is absolutely necessary.