This chapter contains the following sections:
To generate the rendered Desktop user interface (what the industry refers to as the “presentation”), the Sun Java System Portal Server 7.1 software makes use of either JSPs or template files. JSPs are preferred because they enable a much easier customization process without having to change the provider Java classes. JSPs also provide a way to enable a strict separation of business and presentation logic. Specifically, this means having the business logic in the provider classes and presentation logic in JSPs.
The default set of JSPs are installed in /var/opt/SUNWportal/portals/<portal_id>/desktop/default directory. The developer sample JSPs are installed in /var/opt/SUNWportal/portals/<portal_id>/desktop/developer_sample and /var/opt/SUNWportal/portals/<portal_id>/desktop/developer_anonymous_sample directories. Files in the /var/opt/SUNWportal/portals/<portal_id>/desktop/developer_anonymous_sample directory are specific to the developer sample Anonymous Desktop.
The JSPProvider class reads in the JSP, compiles it, and runs it to produce the channel content.
The JSPProvider class reads at most three JSPs, one for content, one for the Edit page, and one to process the form submission from the Edit page. All other JSPs used in a JSP-based channel are referenced from one of those JSPs, either by an include or a forward statement.
A simple JSP-based channel can have just one JSP. Multiple JSPs are useful when a single part of the Desktop has to be replicated in several places. For example, consider a channel that has several display modes based on links clicked in that channel. Further, assume that the channel has a banner that must be displayed in all modes but one. You could construct a JSP to reference a banner.jsp file that captures common formatting that is used in multiple branches of the logic. If you didn’t use this method, you would need to duplicate the content from the banner.jsp file, which is more difficult to maintain if that content needs to be changed.
desktoptype_ locale/ channelname/ clientPath desktoptype_ locale/ provider/ clientPath desktoptype_ locale/ channelname desktoptype_ locale/ provider desktoptype_ locale/ clientPath desktoptype_ locale desktoptype/ channelname/ clientPath desktoptype/ provider/ clientPath desktoptype/ channelname desktoptype/ provider desktoptype/ clientPath desktoptype default_ locale/ channelname/ clientPath default_ locale/ provider/ clientPath default_ locale/channelname default_ locale/ provider default_ locale/ clientPath default_ locale default/ channelname/ clientPath default/ provider/ clientPath default/ channelname default/ provider default/ clientPath default templateroot
If there is no clientPath specified, then the directory search order is as follows:
desktoptype_ locale/ channelname desktoptype_ locale/ provider desktoptype_ locale desktoptype/ channelname desktoptype/ provider desktoptype default_ locale/ channelname default_ locale/ provider default_ locale default/ channelname default/ provider default templateroot
The lookup scenario relies on the following parameters:
For example default (set in the administration console). Note that desktop type is now a comma separated string list and so the look up will be based on the desktop type(s) that are defined in the desktoptype attribute.
Preferred locale is the user’s locale. For example, en_US (set by users through the administration console in the “User” setting)
This is an optional file-path containing client-specific templates; for example, html (set through the administration console Client Detection service)
This is the name of the channel; for example, newSingleContainer (set in the display profile)
This is the provider name; for example, JSPSingleContainerProvider (set in the display profile)
This is defined in the desktopconfig.properties file. The root of the search directory (default value of /var/opt/SUNWportal/portals/<portal_id>/config/) can be changed by modifying the templateBaseDir property in the desktopconfig.properties file.