Over the course of the years, WebLogic has improved significantly in both features and performance. However sometimes with those improvements we need to learn new ways to do things in order to best leverage those changes. Prior to the introduction of tree optimization in 8.1 SP4, creating a site map was a trivial task as you could simply walk the tree of presentation contexts starting with DesktopPresentationContext.

It was trivial because prior to 8.1 SP4, Portal would build the complete control tree where each control in the tree would represent a portal artifact, for example a book, page or portlet. This made walking the tree for a site map quite easy since all artifacts are present. There was a dark side to this however as customers with large portals found that the performance of building the control tree was abysmal and often resorted to techniques like splitting a portal across multiple desktops to work around this issue.

In 8.1 SP4 tree optimization was introduced. This feature, which is on by default, tells the Portal to build a partial control tree rather then a complete one. This means that only the controls that are visible will be in the tree. This greatly improves performance, however it complicates creating a site map since we can no longer walk the available contexts.

Building the Site Map

When developers new to Portal encounter the issue with tree optimization there is usually some scratching of the head followed by the adoption of one of the more obvious ways to work around this issue. Here are some common workarounds:

1. Turn off tree optimization for the Portal. For smaller portals this might be an option but the larger the portal the more impact it will have on performance. Additionally there is the risk that if the portal functionality grows over multiple iterations you may need to turn tree optimization on again breaking the site map. In reality this is not a recommended option.
2. Use the View APIs to walk the tree which provide a complete picture of the Portal. The downside with this approach is that the View objects like BookView are not entitled, thus a user can get artifacts in the sitemap they are not entitled to see which can result in confusion. However, if the Portal does not use entitlements this is a perfectly viable option. Finally this option only works for streaming desktops.
3. Temporarily turn off tree optimization using the _nfto switch. This enables the sitemap to work correctly while the performance is not affected for other pages. The disadvantage is that you need to include _nfto=false on any link pointing to the sitemap page. As a result it limits an administrator's flexibility to modify the Portal layout at runtime since updating links would take a code deployment. Finally, for a large portal you may find performance for the sitemap page significantly hindered by the building of the full control tree.

Of the three options above, the first is a non-starter as turning off tree optimization for the Portal has a whole would seriously impact performance for anything but a trivial Portal. The second two options however are workable particular if we extend the concepts to address the drawbacks presented above.

Thus this article will take an in-depth look at two different options for building a site map. In the first case we will use the presentation context to generate the site map by disabling tree optimization intelligently and automatically so there is no need to worry about manually adding _nfto=false to links. In the second option we will explore the use of the View API in conjunction with manually calculating entitlements to address that limitation.

Before embarking on the specifics of the solutions we first need to discuss the basic architectural elements of the solution that are common to both options.