Portal Page Construction and You

Greetings again from the vaguely abstract and always entertaining blogosphere. Since my last post, an attempt to lay out the basic workings of the EDK, I've been thinking it might be helpful to clarify some of the page construction methods in the portal. One of the frequent questions buzzing around in my head during my early days with the product was "How exactly does all of this page rendering stuff happen?"

First, you should note there is a great explanation of the caching mechanisms the portal uses for portlets in the edocs. The only problem is, the explanation is long, technical, and doesn't cover any of the other rendering mechanisms you are likely to encounter along the way. Thus, as a result of my laziness (see previous posts for details), the only things I have learned about portal caching and page construction have come from doing it the wrong way and suffering as a consequence. Hopefully some of you will benefit from my pain.

Second, this is my understanding of the rending process, based on what I've seen and done with the portal. No one sneaked any blueprints into my office (oh wait, I don't have an office), so even though I'm pretty confident in this stuff, you'll have to excuse any possible technical inaccuracies.

The Whole Enchilada

Let me start with a diagram of my understanding of the page rendering processing. Please note that I am not the Visio ninja some of my colleagues are...

What's going on here? As you can see, the above process is a bit convoluted. In an attempt to clarify, here is a step-by-step description of the page rendering process:

1. User's browser makes an HTTP request to the portal host (IIS or a java application server)
2. Portal host handles the request by parsing the URL and deciphering what portlets and/or server API code must be rendered on a page. Server API code could be the base portal header/footer/top bar, or it could be an intrinsic portlet.
3. Portal host makes requests to the portlet cache for any portlets on the page. If the portlets are in the cache, and the cache entries are still valid (see below for a 5 second caching review, or the edoc section I mentioned earlier), cached HTML is pulled from the cache. Otherwise, requests are made (in parallel) to the various remote URL's to retrieve HTML content.
4. Once all of the portlet content has been retrieved, it is assembled into a complete page. No server API code has been rendered at this point.
5. The partial page compiled from all the remote portlets on the page is next run through a parser, which looks for any <pt> tags and renders them (note this only happens after the page is built).
6. Finally, the rest of the server API code on the page is executed and the page is compiled into its completed from, then returned to the user in an HTTP response.

From the above diagram and accompanying description, you will hopefully note a few things:

• The portlet cache only applies to remote portlets. Anything else is rendered at every page request, and must implement its own cache.
• The tag framework, any intrinsic portlet, and any custom navigation scheme all rely on the same rendering method: the server API, hence they must always exist as libraries on the front-end portal server.
• I am lumping all of ALUI's embedded application servers (Publisher, Collaboration, etc) into Remote Portlet Hosts because that is all they really are (I will address the frequently confusing pcs tags from Publisher later in this post).

So what's the main point? The main point is that if you are going to be developing a custom tag, intrinsic portlet, or custom navigation scheme you need to be hyper-sensitive to performance. Unless it is some sort of administrative feature, your server API code could wind up rendering on the home page of every user in your portal (or even on every page in the portal).

The other main point is that you can't use the tag framework unless you are writing a remote portlet.

5 Seconds on Caching

I don't want to beat a dead horse, since the portal's caching mechanisms are explained very well in the link I provided, but I think it might be worth my time to provide a 5 second summary of that document. In fact, what most people want to know about how caching works is summarized there, albeit at the end of the document, so I'll just repeat it here:

• The Portal Server never makes a request to the remote server before the Minimum Cache Time if there is content in the cache. (In version 6.0, the portlet cache is limited to 15 minutes, so a request will always be made after 15 minutes.) Multiple requests made for the same portlet with identical cache keys within this minimum time always receive cached content. As noted earlier, setting the Cache-Control header to “no-cache” overrides editor caching settings; content will not be cached.

• The Portal Server always makes a request to the remote server after the Maximum Cache Time. Cached content might or might not be returned, based on other information (i.e., the Last-Modified header).

• The Portal Server might or might not make a request to the remote server if content has been cached in between the Minimum and Maximum Cache Time. The Portal Server observes programmatic caching (i.e., the Expires header) in the window between the minimum and maximum times.

If you've done any portlet development or configuration, the above should make quite a bit of sense to you.

What about Publisher?

The final, and often misunderstood, piece to this puzzle is Publisher. A lot of times customers want to know where, when and how Publisher's own rendering framework fits into the portal. And actually, it's pretty simple once you know how it works.

The best way to think of Publisher is to think of it as two pieces: a stand-alone static content host (static HTML and images only), and a publishing product. When a piece of content is published in the publishing product, that is the only time when anything intricate or cool happens. The rest of the time (for instance, when a Publisher portlet is put on a page), Publisher is just serving up a static HTML file with some images or javascript. That's it (well, except for the redirect part, but I'm trying to make a point).

As I mentioned previously, people often confuse the when of Publisher's custom tag rendering scheme (<pcs> tags, like those found in the News Portlet). Those tags are only rendered once: when a document is published. After that, they have been turned into static content for portlets to request. Thus, when I talk about the portal's rendering process, these tags become a moot point. They are never rendered at run time.

Hopefully this clears up some of the confusion.

Something Helpful

At this point I'm hoping you have a complete picture of the rendering process. If not, I'll settle for a partial understanding with a false sense of confidence.

As I have said in a few of these posts, this information is smattered about the documentation, source code, and in some cases, exists only in the late night conversations between consultants who are too obsessed with work to make small talk about sports and the weather (Keith, when are you going to start blogging?). My goal is to give you something in these posts that at some point or another I wished I had read instead of experienced.