Introduction
This is the first to describe the first article of the series of articles developed using IBM WebSphere® Portal Server. First, this series will show how WebSphere Portal Server 2.1 can extend to provide dynamic topic selection. This series will then show how to quickly start all WebSphere Portal Server development activities using IBM WebSphere Studio Application Developer.
Part 1 of this series describes how to achieve dynamic topic customization of Portal Server. Part 2 will explore the development of Portal Server projects using Application Developer in more detail. Let's take a step step by step to create a Portal Server project in Application Developer. Part 3 will explore how to set Application Developer to debug Portal Server applications and find their failures.
This article assumes that you have installed WebSphere Portal Server 2.5.4. You should also be familiar with Portal Server and Application Server management. To see the project source code provided herein, you must have WebSphere Studio Application Developer 4.0.
WebSphere Portal Server
WebSphere Portal Server 2.1 is a product capable of aggregating information and collaboration applications on IBM WebSphere Application Server 3.5.4. Portal Server provides a single point access to a variety of information and applications via portlet. Portlets are visible windows that organize different source organizations to individual interfaces for personal or group access. Most of the underlying technologies used by Portal Server are based on J2EE specifications. Portlets provide visual and programming methods for transmitting information to users. Therefore, we can quickly build enterprise portals through integration of several portlets, and these portlets integrate the infrastructure services provided by the Portal Server framework. Most of the services provided can be further customized by certain programming. With the popularity of WebSphere Portal Server, more and more people in the development community began to learn how to accelerate the development process, and in-depth understand how to do customization.
Figure 1. WebSphere Portal Server default homepage without users logging in
Figure 2. WebSphere Portal Server after users wpsadmin login
WebSphere Studio Application Developer
WebSphere Studio Application Developer provides an extendable integrated development environment for JavaTM-based software development. Application Developer has numerous plugins that shorten the development cycle of very complex projects. Application Developer built-in features and functions make it best to develop WebSphere Portal Server projects.
If the developer chooses VisualAge® For Java as a development platform, the development and debugging environment that supports WebSphere Portal Server is WebSphere Portal Server Testing Environment. When writing this article, Application Developer has built-in support for WebSphere Application Server 4.0 and Tomcat. Because Portal Server is built on WebSphere Application Server 3.5, it does not have a direct reference to how to use Application Developer for Portal Server development. Therefore, "How to" create and manage the Portal Server project using Application Developer to become a common problem in Portal Server developers. To learn more about WebSphere Portal Server Testing Environment, visit the WebSphere Portal Server Support page. Theme (Theme) and Skin
WebSphere Portal Server provides a way to customize the appearance and feel of the portal. The customization function is achieved by the concept of theme and the skin (SKIN). The portal administrator or developer can determine the look and feel of the site by creating the desired bitmap and JSPTM files for the subject and skin. WebSphere Portal Server contains five different topics and four skin. The subjects you can use are:
Defaulttheme Greytheme KhakitHeme Lilactheme Tealtheme
The skin that can be used is:
Album Hint Outline Shadow
The subject determines the color scheme of the banner image, tab image, icon, and portal (using the cascading style sheet), and the skin specifies the look and feel of each portlet on each page. The portal model of WebSphere Portalserver InfoCenter provides a detailed description of the file location of the subject and skin. InfoCenter also provides a good description of how to apply different bitmaps, as well as the size and sizes required for these bitmaps. For the sake of explanation, we refer to Infocenter, and the following table 1 is adapted.
Table 1. Bitmaps on the Default Theme profile
Resource Type Image Sample Note Banner The background in the top of the banner Navigation icon NAV_CUSTOMIZE.GIF Link to the page of the custom portal Navigation icon NAV_CREATE_ACCOUNT.GIF Link to the registered page Navigation icon NAV_FORGOT_PASSWORD.GIF Link to help users from site administrators Request credential page Navigation icon NAV_HELP.GIF Link to the portal help page Navigation icon NAV_LOGIN.GIF Link to the login page Navigation icon NAV_LOGOFF.GIF Link to the logout page Navigation icon NAV_PROFILE.GIF link to the update account information page tab One-angle Tab_LEFT. GIF appears on the tab left tab One-angle TAB_RIGHT.GIF appears at the right portlet title bar title_back.gif to return the portlet from the help mode back to the view mode portlet title Bar Title_Help.gif Open portlet Help Mode Portlet title Bar Title_edit.gif Open portlet editing mode portlet title bar Title_maximize.gif Totlet Titlet to maximize view portlet title bar title_minimize.gif to narrow the portlet to the title bar portlet title Bar Title_Restore.gif From maximize or minimize status Recovery portlet to different topics Activate the theme.default field of the Turbineresources.properties file. You can find the location of the property file in the
Figure 3. Turbineresources.properties file directory location
When WebSphere Portal Server starts, this file is read and resolved, as long as the portal session is available, the THEME.DEFAULT field is maintained in valid.
In addition, the THEME.DEFAULT field does not allow any form of key-value mapping, which will cause a single topic to be used by all Portal Server user sessions.
Listing 1. Fragment of Turbineresources.properties
# ... Some Code Truncated Above ...
#
# This is the default theme to apply to the l & f
#
# Default: Defaulttheme
Theme.default = defaulttheme
# ... Some code truncated below ...
This default behavior (ie, a single topic is used by all Portal Server user sessions), when providing better particle size to customize Portal Server, it will become a limit. Usually, the required particle size is the factor of the following environmental parameters.
User session (for example, login user ID) location (for example, where to browse, or user's IP address) time (for example, is it a school holiday time)
Dynamic topic selection
When the WebSphere Portal Server site needs to change the appearance and feel according to an environment parameter, this parameter must be retrieved at runtime (possibly when making a user request for Portal Server). For example, this situation may be, different users or different user groups need to use different colors and bitmaps. For the portal, it is common based on user preferences. Sometimes, the selection logic programming is built on the company's policy, but more common is that the user specifies its preference. The logic required to achieve dynamic topic selection may be slightly different depending on the operational needs of the subject.
Currently, WebSphere Portal Server does not support dynamic topic selection, because in Turbineresources.properties files, only one separate Theme.default field is defined for all users. Fortunately, as long as you make some simple programming, WebSphere Portal Server can be extended to handle dynamic topic selection. The steps required to implement these changes are as follows: The determination of how environmental parameters and when can be retrieved. See the implementation of GetEnvironparam () in MyThemetag.java download file (more details below). Use environmental parameters as a hash key to derive the theme value. See the implementation of the GetThemetag.java in MyThemetag.java (more details below). Distribute the Meme value. See the implementation of DostartTag () in MyTartTag () in the download file (more details below).
I will provide a functional framework code to illustrate these concepts to describe steps 1 and 3 above. As for Step 2, derived from environmental parameters is usually specific to individual portals. Typically, this can be implemented by using a simple lookup table or from database table reading value. Now, we will be displayed by initializing the hash table in memory whenever WebSphere Portal Server starts.
The next section describes how to extend Portal Server to provide UI customization, which allows the use of extended environment parameters to affect the topic selection.
As mentioned above, each subject defined in WebSphere Portal Server consists of a set of user interface entities or resources. Portal Server developers can flexibly customize these resources such as images, banners, and various style sheets (.css files). These style tables contain the color and font type of the subject. When the Portal Server kernel generates an HTML code from the JSP file, the reference to these .CSS files is inserted, so that the user's browser finds these style sheets from the browser side to customize the page.
Portal Server uses the concept of the JSP tag to perform the task of dynamic field replacement. The JSP tag has two components in nature: a tag handler implemented using Java code and an XML tag element. Whenever a tag element occurs in a JSP file, the associated tag handler Java code is executed. Java execution code also affects how to generate the label when the tag is generated.
WebSphere Portal Server allows developers to implement and provide user-defined custom tag libraries. These user-defined tags can be used to further enhance the portlet page processing. In addition to the developer's custom marker, Portal Server also implements a set of tag library functions used by the Portal Server engine. This is called Engine Tag Library or Engine.TLD. You can find the location of the file in the
Figure 4. Directory location of Engine.TLD file
If you study the engine.tld file more carefully, you will find how the tagger command is registered and declared.
Listing 2. Fragment of Engine.TLD
... Some Code Truncated ABOVE ...
... Some Code Truncated Below ...
Please join the
Listing 3. The subject mark registration in Engine.TLD
... Some Code Truncated ABOVE ...
... Some Code Truncated Below ...
The subject tag defined by WebSphere Portal Server does not accept any parameters, and the topic's implementation will return the name of the topic. The returned value will become a actual file, which is exported from Portal Server to its web folder. For example, use
Listing 4. Fragment of Banner.jsp
// ... Some Code Truncated Above ...
Background = '
// ... Some Code Truncated Below ...
When Banner.jsp is compiled and returned to a user's browser, the following HTML code is generated:
Listing 5. HTML file fragment generated from banner.jsp
// ... Some Code Truncated Above ...
Background = 'http://babylon5.sg.ibm.com/wps/
Portal / Images / Themes / Tealtheme / Banner.jpg '>
// ... Some Code Truncated Below ...
The JSP tag engine will replace the
To achieve dynamic topic selection, you need two changes to the Portal Server system:
Modify Engine.TLD to reflect the Java code selected by the new processing topic. Implement a new THETAG class that performs dynamic topic selection and loads it into the Portal Server instance.
In fact, we can implement a new tag (such as
Let us use the more common way - override the original behavior of themetag provided by Portal Server.
Engine.TLD
You need to make the following changes in the engine.TLD file.
Listing 6. Change to be made in engine.TLD
Note that we use our own com.ibm.etc.wps.tags.mythemetag to replace the Java class in
Mythemetag.java
MyTHEMETAG.JAVA class implements dynamic selection logic, which inherits the original ThemeTag class in the com.ibm.wps.Engine.Tags package. When the marker handler code is called by the JSP processor, the dostartTAG () method will be called first. As a result, environmental parameters are obtained through the getEnvironparam () method. If you want to retrieve a different environmental parameter, then this is where you should insert a change. Otherwise, the code will remain unchanged and obtain the user login ID derived from the Rundata object. Use environmental parameters as a key, the GetTheme () method is called to obtain the desired subject value. Our implementation is to match the lague table identified by the user with the subject matter. In your specific implementation, this field can be stored as part of the relational database table used by the Portal Server, or can be derived from some logically. More ingenious implementations may be a topic value from the hash table accepted by the user ID, IP address, and date / time group. This form of customization provides a better UI custom particle size to Portal users.
See the download file below to understand the implementation of MyThemetag.java.
Run change
In the download zip file below, you will find a pre-established version of the MyTheme.jar project, a modified engine.TLD file and all source code that appears in this article. All required JAR files are embedded when the project is created. So when you try to use Application Developer to recompile to any errors that lost JAR files. I will discuss the development of Portal Server projects in the Part 2 of this series.
If you are familiar with using Application Developer, continue importing items into a workspace environment and start building a code. Otherwise, simply copy the MyTheme.jar file to the
Next, start your WebSphere Application Server Management Console and add the MyTheMe.jar path to the classpath of the Portal Server Web Application. This will ensure that the Portal Server's JSP processor is able to locate the new topic tag handler. Finally, delete any cached portal page stored in the
Once all of these changes have been made, restart the WebSphere Portal Server Application Server from the WebSphere Application Server management console to view the change!
Figure 6. WebSphere Portal Server Default Homepage without User Login
Figure 7. WebSphere Portal Server after users wpsadmin login
The above, and Figure 6, both show the default WebSphere Portal Server Home page without the user logged in to Portal Server. Please note that they have different color schemes. In FIG. 6, the dynamic subject selection is triggered, and select Greytheme for "guest" or page with no user ID. Similarly, in Figure 7, the logged in user "wpsadmin" receives a different topic Tealtheme (more compared to the default implementation shown in Figure 2). Switch between this different group subject is dynamically occurring according to the realization of the MyTHEMETAG :: DostartTAG () method. Keep in mind that the turbineresources.properties file does not change, and the WebSphere Portal Server Application Server is not restarted.
to sum up
This article and the code are shown to extend the possibility of WebSphere Portal Server by overlying the default behavior of the Portal Server class. With the same principle that overrides the marker handler default implementation, there are many different customizations to be added to Portal Server with a highly personalized portal. For example, it can be an overlay
You can further extend the sample code shown in this article to provide customizer pages, for users to request a request for topic selection (or other types of UI habitual options) and store values to some kinds of memory (such as database).
The implementation of this approach is developed on the basis of Portal Server 1.2 code, because the reason for writing this article has been ported to Portal Server 2.1. Between Portal Server 1.2 and Portal Server 2.1, the mode of marking engine work is also a little different. If you need code designed to use Portal Server 1.2, please contact the author. Related reference
Portlet Definition WebSphere Portal Server InfoCenter WebSphere Portal Server Portlets Catalog Introduction To Portlets API Advanced Introduction To Portlets API
