|
| |
| Sun Java System Portal Server 6 2005Q1 Desktop Customization Guide | |
Chapter 15
Miscellaneous JSP and Template InformationThis chapter contains the following sections:
This chapter contains miscellaneous information on using JSPs and templates when customizing the Desktop.
Performing JSP RedirectsTo perform redirects from the doedit.jsp page back to the edit.jsp page, use the following URL:
response.sendRedirect(p.getProviderContext().getDesktopURL(request).toStrin g() + "?action=edit&provider=ipsdtJSPEditChannel" + "&targetprovider=" + p.getName() + "&reedit=true");
To return back to the Edit page, use the following, which does not hardcode the editchannel name.
JSP vs. Theme ColorThe colors of a theme can be changed in two places: in the JSP or template file that uses the theme tag, and in the display profile using the GlobalThemes attribute.
If you change the color value in the JSP or template file, the Desktop uses this value and not what is in the GlobalThemes attribute.
For example, if you manually change the following background color in a JSP file
BGCOLOR="<dttheme:getAttribute name="borderColor"/>"
to
BGCOLOR="#FFFFFF"
then the Desktop shows white for border color, and the theme color is not used. There is no way the theme or the Desktop can detect this.
Recompiling JSPsEvery time you make a modification to a JSP file, you need to recompile. You do this by running the touch command on the modified container’s top-level JSP file.
For example, type touch tab.jsp.
Note
A typical desktop will include content from several JSPs. However, if you make a modification to a non-toplevel JSP that has been included in a top level JSP, the included JSP will not be recomplied. The end result is your desktop changes will never be reflected.
If the top-level JSP is touched, the JSP engine recompiles all the relevant JSPs. If you cannot find the top level JSP, run the touch command on all JSPs in the directory, for example,
touch *.jsp
This modifies all JSPs, including the top-level JSP.
See JavaServer Page Caching Information for information on how to find the top-level (parent) JSP.
JavaServer Page Caching InformationWhen the system compiles JavaServer Pages™ (JSP™), the result is only one Java™ class per parent JSP. There is no compiled class for the static included JSPs. Thus, when you change an included JSP, you need to run the touch command on the parent JSP to recompile the parent JSP with the changed JSP. The Portal Server software JSP engine checks the last modification time on the compiled class and the JSP file to see if the JSP needs to be recompiled. In this way, the change takes effect immediately.
To find a JSP’s parent JSP, search in the JSP for the string <%@ include file="filename.jsp" %>. Some JSPs are dynamically included by using the <jsp:include page="header.jsp" flush="true"/> syntax instead of <%@ include file="header.jsp" %>. This syntax compiles header.jsp and generates a separate Java class.
The path to cached JSPs is constructed in such a way so that the compiled JSPs do not conflict with each other in multi-server instances, when multiple Desktop types contain the same JSPs and for multiple clientTypes and locales. So when JSPs are dynamically included, the touch command does not need to be run for the parent JSP.
Debugging JSPsThe JSP classes are created at:
/var/opt/SUNWps/https-psservername/portal/tmp/_jsps
You can find compilation and runtime errors in the Desktop debug log at:
/var/opt/SUNWam/debug/desktop.debug
Also, all JSPProvider based Desktop channels have a property called showExceptions. This property, by default, is set to false; setting it to true causes the JSP exception to show up as the content of the channel.
Dynamic Template ReloadingIf you make changes to the Desktop templates, note that these templates are dynamically reloaded. The reload interval is by default set to thirty seconds. You can change the reload interval in the desktopconfig.properties file at /etc/opt/SUNWps/desktop directory.
To Change the Template Reload Interval