One of the many web site headaches that portal technology was expected to cure is the need for IFrames to integrate content and functionality between web applications. Portals provide a quick, clean approach to combine multiple applications into a single user interface. Intranets rapidly adopted the portal approach to combine the multitude of employee content and self-service applications into a single starting place with great success. The employee portal had two huge advantages over the earlier collection of internal sites, vendor sites, and emails: The employee only needed one URL to find what they needed, and they used it.

External facing portals have also enjoyed a rapid adoption, and they tend to evolve along one of two common paths. The first path is where a company had a small web presence when they adopted the portal approach. These companies could easily build a new portal that combined all of their URLs to a single location and then expand functionality as their web business grew. The other path is where a business was an early adopter of the web as a place to do business with their customers and enjoyed a very rapid return on their technology investment. These companies worked to rapidly expand their success by providing more and more web access for their customers. Whether driven by time to market requirements, external competition, internal competition, or just plain short-sightedness, the new web applications would have unique URLs, different architectures, and developed on whatever language was preferred by a department or decision maker. As with the Intranets, it became apparent that a portal would expose more people to more functionality and increase the technology ROI.

As IT professionals, we all know how difficult is to explain to non-developers that just because all of these features are already web-enabled it is still takes some time to pull them all together. And, we all know that we will eventually have to provide twice the functionality in half the time we need to do it right. In the case of portal integration, one short cut that always comes up is the use of the IFrame, which we thought portals were supposed to save us from.

So, there you are, stuck with using an IFrame to bring in legacy web applications to your portal to meet a deadline (after which you can campaign to "upgrade" the applications to proper portlets). For content-only sites and simple web applications, WebLogic Portal (WLP) has built-in features that make this pretty simple. In version 9.2, WLP introduced the Browser Portlet; it was perfect for pulling in content from other sites. The WLP team introduced an improvement with the release of 10.0, the Clipper Portlet. In many cases, these two approaches will allow you to pull in your external URL in no time flat. They both have two drawbacks that may make them unsuitable to your particular application. One is that you have to define the size of the portlet at design time. There are plenty of web applications where the first screen of a given workflow is smaller than subsequent screens, which makes this awkward. The other drawback is that the URL is defined at design time. If you already have a track scheduled to upgrade the external application to portlets and are confident that what is in production now will be the same until you do, this isn't an obstacle. This is often the exception to the rule, however.

The advantage of a portal framework such as WLP is that it provides frameworks that allow you to simply write code and not worry about how everything will get assembled into an integrated presentation and navigation model. To enjoy the full advantages of such frameworks, you want to always use an out-of-the-box (OOTB) feature before going off to design your own. When it comes to rendering a legacy application inside the portal using an IFrame, you can still do it with OOTB features, though you need to think just a bit out of the box to see how it will work.

A basic portal consists of a header, navigation, content, and a footer. In portals, the content is generally portlets, and the content area is designed to hold portlets, making filling the content area with an IFrame a somewhat daunting experience. The easiest way to define an IFrame so that you don't need to worry about the size of the content is to set its width and height at 100%. However, if you create a portlet to hold a JSP containing a IFRame of 100% X 100%, you only get as much space as you defined at design time (either through portlet properties or CSS). Figure 1 shows the worst-case scenario of no design-time definition:

Now, think outside the box. The key elements that make up your portal are the header, navigation, content, and footer. Of those four elements, three of them are rendered by a direct counterpart within the look and feel framework, specifically within the skeletons (this is a bit of a simplification, but accurate enough to lead you to your solution). The odd part out here is content, which is rendered by a group of skeleton files. For a page with a single portlet, the basic skeleton files would be the page.jsp, gridlayout.jsp, placholder.jsp, titlebar.jsp. and window.jsp. The resulting HTML for all of this looks like this: