A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
This is the first article in the series that describes how to use IBM WebSphere Portal Server for development. First, this series shows how WebSphere Portal Server 2.1 can be expanded to provide dynamic theme choices. The series then shows how to use IBM WebSphere Studio application developer to quickly start all WebSphere Portal Server development activities.
Part 1 of this series describes how to implement dynamic theme customization for Portal Server. Part 1 will discuss in more detail the use of application developer's Portal Server project development. We will guide you step by step in creating a Portal Server project in application developer. Part 1 describes how to set application developer to debug Portal Server Applications and find their faults.
This document assumes that you have installed WebSphere Portal Server 2.1 and WebSphere Application Server 3.5.4. You should also be familiar with Portal Server and Application Server Management. To view the project Source Code provided in this article, you must install WebSphere Studio Application Developer 4.0.WebSphere Portal Server
WebSphere Portal Server 2.1 is a product that can host clustering information and collaboration applications on IBM WebSphere Application Server 3.5.4. Portal ServerPortletThis concept provides site users with a single point of access to a variety of information and applications. A Portlet is a visual window that organizes content from different sources to a separate interface for personal or group access. Most of the underlying technologies used by the Portal Server are based on J2EE standards. The Portlet provides a visual and programming method for transmitting information to users. Therefore, we can quickly build an enterprise portal by integrating several Portlet, which integrates the infrastructure services provided by the Portal Server framework. Most of the services provided can be further customized through certain programming. With the popularization of WebSphere Portal Server, more and more people in the development community are interested in learning tools available to accelerate the development process and how to implement customization.
Figure 1. WebSphere Portal Server default homepage without user logon
Figure 2. WebSphere Portal Server after wpsadmin Logon
WebSphere Studio Application Developer provides a scalable integrated development environment for Java-based software development. Application developer has a large number of plug-ins that can shorten the development cycle of very complex projects. The built-in functions and functions of application developer make it the most suitable for developing WebSphere Portal Server projects.
If the developer chooses visualage for Java as the development platform, the development and debugging environment supporting WebSphere Portal Server is WebSphere Portal Server testing environment. At the time of writing this article, application developer has built-in development support for WebSphere Application Server 4.0 and tomcat. Because the Portal Server is built on WebSphere Application Server 3.5, there is no direct reference for how to use application developer to develop the Portal Server. Therefore, "how to" use application developer to create and manage a Portal Server project becomes a common problem for Portal Server developers. For more information about WebSphere Portal Server testing environment, visit the WebSphere Portal Server support page.Theme and skin)
WebSphere Portal Server provides an easy way to customize the appearance and feeling of a portal website. The custom function isTheme)AndSkin (skin). Portal administrators or developers can create bitmap and JSP files for themes and skins to determine the site's appearance and feeling. WebSphere Portal Server contains five different themes and four skins. The following topics can be used:
Available skins include:
The topic determines the color scheme of the banner image, Tab image, icon, and portal website (implemented using Cascading Style Sheets), while the skin specifies the appearance and feeling of each Portlet on each page. The portal modification section of Websphere portalserver infocenter provides a detailed description of the file location of the topic and skin. Infocenter also provides a good description of how to apply different bitmap schemes, as well as the size and size required for these bitmaps. For the sake of illustration, we can refer to infocenter to adapt table 1 below.
Table 1. bitmap of the default theme Profile
Resource Type Image sample Note Banners Appear in the background in the upper-left corner of the Banner Navigation icon
Link to the custom portal page Navigation icon
Link to the self-registration page Navigation icon
Link to the page that helps users request creden from the site administrator Navigation icon
Link to the portal Help Page Navigation icon
Link to the logon page Navigation icon
Link to the logout page Navigation icon
Link to the page for updating account information Tab corner
Appears on the left side of the tab Tab corner
Appears on the right of the tab Portlet title bar
Return the Portlet from the help mode to the view mode Portlet title bar
Open the Portlet help Mode Portlet title bar
Enable the Portlet editing mode Portlet title bar
Open the Portlet to maximize the view Portlet title bar
Narrow down the Portlet to the title bar Portlet title bar
Restore A Portlet from the maximized or minimized state
You can modify the selection of different topics.
theme.defaultField. You can
Figure 3. directory location of the turbineresources. properties File
When the WebSphere Portal Server is started, the file is read and parsed, as long as the portal session is available,
theme.defaultThe specified value of the field remains valid.
theme.defaultFields do not allow any form of key-value ing, which causes a single topic to be used by all Portal Server user sessions.
Listing 1. Fragments of turbineresources. Properties
# ...Some code truncated above... ## This is the default theme to apply to the L&F## Default: DefaultThemetheme.default=DefaultTheme# ...Some code truncated below...
This default behavior (that is, a single topic is used by all Portal Server user sessions) becomes a limitation when you need to provide a better granularity to customize the Portal Server user interface. Generally, the granularity is the factor of the following environment parameters.
When the WebSphere Portal Server site needs to change its appearance and feeling according to an environment parameter, this parameter must be retrieved at runtime (possibly when a user request to the Portal Server is made. For example, different users or user groups need to use different color and bitmap sets. It is common for portal websites to provide UI Personalization Based on user preferences. Sometimes, logic-based programming is based on company policies, but it is more common for users to specify their preferences. The logic required for dynamic topic selection may be slightly different Based on the operation requirements of topic selection.
Currently, WebSphere Portal Server does not support dynamic topic selection because
TurbineResources.PropertiesFile, only one
theme.defaultField is defined. Fortunately, with some simple programming, WebSphere Portal Server can be extended to handle dynamic theme choices. The steps required to implement these changes are as follows:
getEnvironParam()(More details are provided below ).
getTheme()(More details are provided below ).
doStartTag()(More details are provided below ).
I will provide functional framework code to illustrate these concepts and describe in detail steps 1 and 3 above. As for Step 2, the theme value derived from the environment parameter is usually specific to individual portals. Generally, this can be achieved by simply searching for a table or reading values from a database table. Now we will use a hash list initialized to the memory whenever the WebSphere Portal Server is started.
The next section describes how to expand the Portal Server to provide UI customization, which allows the use of extended environment parameters to influence topic selection.<WPS: Theme> uncover secrets
As mentioned above, each topic defined in WebSphere Portal Server consists of a set of user interface entities or resources. Portal Server developers can flexibly customize images, banners, and various style sheets (
.cssFiles. These Style Sheets contain the subject color and font type schemes. When the Portal Server kernel generates HTML code from the JSP file
.cssFile Reference is inserted, so that the user's browser will find these style sheets from the browser to customize the page.
The Portal Server uses the JSP tag concept to perform the task of replacing dynamic fields. In essence, JSP tag has two components: a tag handler implemented using Java code and an XML tag element. When a tag element appears in a JSP file, the Java code of the corresponding tag handler is executed. Java code execution also affects how tags are processed when tags are generated.
WebSphere Portal Server allows developers to implement and provide custom tag libraries. These User-Defined tags can be used to further enhance the processing of the Portlet page. In addition to the developer's custom tag library, the Portal Server also implements a set of tag library functions used by the Portal Server engine. This is called the engine tag library or
Engine.tld. You can
<WPS_Install_Root>/app/web/WEB-INF/tldFolder. You can find a detailed description of the features marked by each engine in the changing the portal layout section of Websphere portalserver infocenter.
Figure 4. directory location of the engine. TLD File
If you study
Engine.tldFile, you will find how the tag commands of the tag library are registered and declared.
Listing 2. Fragments of engine. TLD
...Some code truncated above...<tag> <name>url</name> <tagclass>com.ibm.wps.engine.tags.UrlTag</tagclass> <bodycontent>empty</bodycontent> <attribute> <name>type</name> <required>true</required> </attribute></tag>...Some code truncated below...
Add both ends of the engine tag
<tag>Element to declare it.
<name>The element defines the tag element name used in the JSP file.
<tagclass>The implementation part of the element identification tag element.
<attribute>Tags can include more parameters required for JSP-tagged implementation classes.
Listing 3. Topic tag registration in engine. TLD
...Some code truncated above...<tag> <name>theme</name> <tagclass>com.ibm.wps.engine.tags.ThemeTag</tagclass> <bodycontent>empty</bodycontent></tag>...Some code truncated below...
The theme tag defined by the WebSphere Portal Server does not accept any parameters. The implementation of the theme tag handler returns the name of the topic. The returned value is the actual file, which is exported from the Portal Server to its Web Folder. For example
Listing 4. Banner. jsp snippets
// ...Some code truncated above...<TD class="wpsPortalBanner" valign="middle" align=left width="499" height=43 background='<wps:url type="base"/>images/themes/<wps:theme/>/banner.jpg'>// ...Some code truncated below...
Banner.jspCompiled and returned to the user's browser, the following HTML code is generated:
Listing 5. html file fragments generated from banner. jsp
// ...Some code truncated above...<TD class="wpsPortalBanner" valign="middle" align=left width="499" height=43 background='http://babylon5.sg.ibm.com/wps/ portal/images/themes/TealTheme/banner.jpg'>// ...Some code truncated below...
Based on the location and method of WebSphere Portal Server installation, the JSP tag engine will be replaced with the relevant URL path
<wps:url>Mark the command.
theme.defaultThe tealtheme value specified by the field.
To achieve dynamic theme selection, you need to make two changes to the Portal Server System:
Engine.tldTo reflect the Java code selected for the new processing topic.
ThemeTagClass, and load it into the portal server instance.
In fact, we can implement a new tag (for example
<mywps:dyna_theme>) And avoid modification.
Engine.tldFile. The disadvantage of this method is that you must add this newly introduced tag to all JSP files related to theme processing used by the Portal Server.
Let's use a more common method-overwrite the original themetag behavior provided by the Portal Server.Engine. TLD
Engine.tldFile to make the following changes.
Listing 6. changes to be made in engine. TLD
<tag> <name>theme</name> <tagclass>com.ibm.etc.wps.tags.MyThemeTag</tagclass> <bodycontent>empty</bodycontent></tag>
Please note that we use our own
<tagclass>Java class. The result of this operation is to request the JSP processor of the portal server to execute our own theme tag processing program.
MyThemeTag.javaClass implements the dynamic selection logic, which inherits
ThemeTagClass. When the tag handler code is called by the JSP processor,
doStartTag()The method is called first. Result: The environment parameter is
getEnvironParam()Method. If you want to retrieve a different environment parameter, this is where you should insert the change. Otherwise, the Code remains unchanged and
RunDataUser Logon ID derived from the object. Use environment parameters as the key,
getTheme()Method is called to obtain the expected topic value. Our implementation is to match the hash list of user IDs with the topic values. In your specific implementation, this field can be stored as a part of the Portal Server's user-preferred relational database table, or derived from a logic. A more sophisticated implementation may be to retrieve the topic value from the hash list that accepts the user ID, IP address, and date/time group. This form of customization provides portal users with a better UI customization granularity.
For more information, see download files below.
In the following download ZIP file, you will find
mytheme.jarA pre-created version and a modified version of the project
engine.tld File and all the source code in this article. All required jar files are embedded during project creation. Therefore, when you try to use application developer to re-compile, you will not encounter any errors that may result in JAR file loss. In part 1 of this series, I will discuss in more detail the development of the Portal Server project.
If you are familiar with using application developer, continue to import the project to the workspace environment and start building code. Otherwise
<WPS_Install_Root>/app/web/WEB-INF/tldDirectory. Back up data if you want.
Figure 5. Add mytheme. jar to the Portal Server class path
Next, start your WebSphere Application Server console, and then
mytheme.jarPath to the Portal Server Web application class path. This ensures that the JSP processor of the Portal Server can locate the new theme tag handler. Finally, delete
<WAS_Install_Root>/temp/default_hostAny cached copy of the portal page in the directory. You can safely delete all files found in this folder because they are usually generated and cached for performance reasons.
Once all these changes are made, restart the WebSphere Portal Server application server on the WebSphere Application Server console to view the changes!
Figure 6. WebSphere Portal Server default homepage without user logon
Figure 7. WebSphere Portal Server after wpsadmin Logon
Figure 1 and figure 6 above show the default WebSphere Portal Server homepage that no user has logged on to the Portal Server. Note the differences in their color schemes. In figure 6, the dynamic topic selection is triggered and greytheme is selected for the "guest" or page without a user ID. Similarly, in figure 7, the login user "wpsadmin" receives a different theme (Please compare this with the default implementation shown in Figure 2 ). Switching between different groups of topics is based on
MyThemeTag::doStartTag()Method implementation occurs dynamically. Remember,
TurbineResources.PropertiesThe file is not changed, and the WebSphere Portal Server application server is not restarted.
This article and the Code demonstrate the possibility of extending the WebSphere Portal Server by overwriting the default behavior of the Portal Server class. Using the same principle as the default implementation of the overwrite tag handler, there are many different customizations that can be added to the Portal Server of a highly personalized portal website. For example, it can be Overwrite
<wps:page>Tag the handler and provide value-added services (such as internationalization) to the name of each page ).
You can further expand the sample code shown in this article to provide the customizer page for your requests for Topic Selection (or other types of UI habits, and persistently store values to a storage (such as a database.
Initially, the implementation of this method was developed on the basis of the Code of Portal Server 1.2. Due to the reasons for writing this article, it has been transplanted to Portal Server 2.1. There is a small difference between the way the tag engine works between Portal Server 1.2 and Portal Server 2.1. If you need code designed to use Portal Server 1.2, contact the author.References
Start building with 50+ products and up to 12 months usage for Elastic Compute Service