Open Source-Based Portal-Lite
If a picture is worth a thousand words, a live demo is worth a million. The problem is that a live demo takes as much work as the real thing and is frequently a throw away. Quality demos also can often require almost as much hardware and software as the final product, making it difficult to get enough funding to build something to get funding. Most difficult of all, it is seldom the person who wrote the demo who will present it, so it must be both simple to use and portable.
In the case of building a Proof Of Concept (POC) for a portal, you can solve all of the above by using the Open Source Apache Struts running on Jakarta Tomcat. With only a few lines of code and minor modifications, you can build a demo portal that can be run on a laptop by anyone who knows how to click an icon.
The key to the POC portal is in leveraging Struts Tiles. Portals are, in essence, a set of consistent layouts with different components. Struts Tiles are a continuation (seems like a replacement, now) of Struts Templates. Tiles leverage the JSP include feature to facilitate the reuse of presentation components in a consistent manner. Having built many portals as a consultant, the first time I saw a Tiles example (in someone else's online article for which I have lost the URL), I thought, "That is a portal."
Tiles vs. Templates
One major improvement Tiles has over Templates is the use of runtime values1. This feature makes it easy to create portal page layouts with Tiles that are reusable. Tiles also make it easy for sharing values between components (if you've ever hand-coded JSPs using includes that need to share values, you can appreciate anything that makes this easier). It's this combination of features that you can leverage to create a flexible and reusable portal POC framework.
Anatomy of a Portal
A portal framework consists of a header, footer, navigation, page, and portlets. Pages have layouts, and portlets are made up of a container, a title bar, and a body. The portlet body is where your individual components live, so everything else is reusable.
In this article, you'll look at the configurations and components necessary to create a very simple portal. Once you understand the basics, you can build as complex of an application as you like.
Building the Portal
For each element of our framework, you need at least one JSP. Because this is not an article on UI development, the JSPs will consist only of a line of text that identifies the file name and the related CSS value so that, when the application is running, these components will be obvious in the browser (also a convenient way to hand off your demo app to a UI developer to add a pretty face). Each framework JSP needs to have access to the Tiles API and any necessary messages. A fairly simple example is your header:
<%-- header.jsp --%> <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ page import="java.util.Calendar, java.text.DateFormat"%> <% Calendar c = Calendar.getInstance(); DateFormat df = DateFormat.getDateInstance(DateFormat.LONG); df.setCalendar(c); %> File: header.jsp Class: portal-body-header <span style="position:absolute; top:35px; right:10px"> <%= df.format(c.getTime()) %> </span>
The date functionality is included here to make it immediately obvious to the casual audience that your demo is more than just static HTML.
Working from the opposite end, most portals have a footer. Because demo applications frequently do not have enough data to fill a 1024X768 screen, you'll use a little scripting2 to make sure the footer stays at the bottom of the page, like this:
The remainder of your JSPs will reference information from the Tiles configuration file (tiles-defs.xml), so you should build that next.
Inside the <tiles-definitions> tags in tiles-defs.xml, you'll configure your framework, starting with your first layout:
<!-- LAYOUTS --> <definition name=".mainLayout" path="/framework/body.jsp"> <put name="title" value="Portal POC" /> <put name="header" value="/framework/header.jsp" /> <put name="footer" value="/framework/footer.jsp" /> <put name="container" value=".container" /> <put name="page" value=".page" /> <put name="menu" value=".mainMenu" /> <put name="titleBar" value=".titleBar" /> <!-- These will create navigation --> <putList name="navLabels"> <add value="Home" /> <add value="Directory" /> <add value="Resources" /> </putList> <putList name="navLinks"> <!-- SEE struts-config.xml --> <add value="home.do" /> <add value="directory.do" /> <add value="resources.do" /> </putList> </definition>
With the above configuration, you are setting your mainLayout page as /framework/body.jsp, which is where you will begin the assembly of your portal components. The other entries set values that can be used in your portal for layout and presentation. The title element for, example, is simply a string used as a consistent way to access values.
Note: Although not necessary, it is good to make it a habit to avoid hard coding values whenever possible so that you will be able reuse more of your POC work in a production application or to give to junior team members as a template for development.
The putList values will be used for building your navigation. How this works will become clearer as you build the other pieces required for a portal-style navigation.
Values that start with a "." are defined separately, as shown below:
<!-- Framework Items --> <definition name=".page" path="/framework/page.jsp" /> <definition name=".container" path="/framework/container.jsp" /> <definition name=".titleBar" path="/framework/titlebar.jsp" /> <definition name=".mainMenu" path="/framework/horizontalmenu.jsp" />
Although the simple examples shown here may not fully utilize this design all of the framework items above, they are included to convey the flexibility your "lite" application can provide (one such application is currently in production at a global corporation). Also, most of the demo code in this article is re-used from an application I use to introduce developers to portal concepts.