Imported Page builder inputsAdded by IBM on June 28, 2011 | Version 1 (Original)
|This topic describes the inputs for the Imported Page builder.
This topic describes the inputs for the Imported Page builder.
- General inputs
- URL Handling
- HTTP Basic Authentication
Table 1. General inputs
|Name||Enter a name for this builder call. The WebSphere® Portlet Factory Designer displays this name in the builder call list.|
|Page to Import (URL)||Enter the URL or the file name of the HTML file to import.
- If you enter a relative path or URL, the builder assumes it is stored in the servable_content_root directory. The HTML code in the file is converted to XML as part of the import process.
- If you are importing a remote page, try following the specified URL with a slash character (/), if the page is not imported correctly. For example, if you specify, http://www.company.com and the page is not imported, change this value to http://www.company.com/.
|Edit Page button (appears only for local, file-based imports)||Click the Edit Page button to read the file and place its contents into an edit field. Click the Cancel Editing button to discard your edits, or click the Save Page button to save your changes.|
|Post Form||Enable this input to force a POST of the form (rather than a GET). Post is recommended for most situations, especially when working with IBM® portlets.|
|Import Rule||Select one of the following: |
Import when builder call is saved (design time only)
Enable this setting for pages that you anticipate will not change often. This option provides better performance because the page is not imported every time the model is generated.Import on each generation of this model
Enable this setting if the page changes frequently. There is a performance hit associated with importing pages every time the model is regenerated.
Table 2. URL Handling inputs
|URL Modification||Use this input to determine how URLs on the imported page are handled. You can choose: |
Do not modify URLs
To keep imported URLs unchangedCreate Relative URLs
To modify imported URLs to a relative contextCreate Absolute URLs
To modify imported URLs to an absolute context. Enable this setting if the imported page contains relative URLs. When the page is inserted in another page, these URLs remain functional.
Note: If IBM WebSphere Portlet Factory is running as a non-default application on the server and the imported page is stored locally, this option must be selected.
|Use JSP Code||Enable this input to construct URLs at runtime using JSP code. This avoids hard coding URLs on the page and allows for dynamic URL generation.|
|Add Base tag||Enable this setting to allow the browser to resolve relative URLs within the imported page. The builder assumes that the directory containing the online help file is the base directory.|
There might be cases when you would want to use a <base /> tag instead of converting to absolute URLs. If your page is embedded in some other page or web site that also defines a <base /> tag, your URLs might not be correct.
Table 3. Encoding inputs
|Encoding||To use encoding other than what the running application server is using (typically US-ASCII or ISO-8859-1), enter the alternative encoding. This feature supports any encoding supported by the java.util.Locale object. The encoding shipped with the Java™ Virtual Machine is listed in the java.lang package in the WebSphere Portlet Factory API.|
|Output Encoding||This input governs the Java character encoding scheme used for outbound HTTP. |
To use encoding other than what the running application server is using (typically US-ASCII or ISO-8859-1), enter the alternative encoding. This feature supports any encoding supported by the java.util.Locale object. The encoding shipped with the Java Virtual Machine is listed in the java.lang package in the WebSphere Portlet Factory API.
HTTP Basic Authentication
Table 4. HTTP Basic Authentication inputs
|User Name||Enter the user name required to view the imported page.|
|Password||Enter the password required to view the imported page.|
Table 5. Advanced inputs
|Fully Parse Page||Normally, WebSphere Portlet Factory runtime parses only nodes with a name attribute and certain special nodes, such as form, body, and head. Other nodes are left unparsed. Partial parsing is more efficient, both in time and memory, and it makes the parser somewhat more tolerant of poorly-formed HTML. Many odd constructions of HTML that are tolerated by browsers but are not, in fact, legal HTML, can be overlooked by the more tolerant parser. |
Check this input to have the page fully parsed. This is especially useful to use advanced PageLocations on the page or when using XPath references in your PageLocations.
|Relative URL Context||Select one of the following if the imported page contains relative URLs: |
Use WebSphere Portlet Factory's servable_content_root
WebSphere Portlet Factory assumes the relative URLs within the imported page are stored in the WebSphere Portlet Factory servable_content_root directory. This is the default and it means that absolute URLs are generated to be relative to the WebSphere Portlet Factory servable content area, which generally means adding the current app context name to the generated URL. For example: /images/foo.gif is changed to http://some.com/MyApp/images/foo.gifUse servable_content_root of the web server's default application
WebSphere Portlet Factory assumes the relative URLs within the imported page are stored in the servable_content_root directory of the web server default application. In the rare case that you want /images/foo.gif to refer to the server servable content root (no added app context), select Use servable_content_root of the web server's default application. The use case for this non-default behavior is a shared images directory used by more than one application.
Table 6. Overwriting input
|Rename Existing||This input is useful to change the behavior of code that was placed in the WebApp by a high-level builder or by an Imported Model builder. |
For example, you might want to do this if you have a Domino® View and Form builder in your model, and you want to use a different class for one of the LJOs that builder adds to the WebApp. The Domino View and Form builder does not provide an LJO Class Name input. But, you can place a new LJO builder in the model and give it the same name as that assigned by the Domino View and Form builder, thus replacing the existing LJO and specifying new class.
When checked, this input causes the builder to replace an existing WebApp object with a new object. The builder locates the existing WebApp object (variable, or LJO, for example), renames it, and creates a replacement object.Note: This input is available on the following low-level builders that create WebApp objects: Action List, Imported Page, Linked Java Object, Linked Model, Method, Method Call, Page, Variable, and Schema.
Parent topic: Imported Page builder