August 2005« February 2006 | Main | June 2005 »
Portal's Flexible Framework Saves The Day
If I had to pick my favorite feature about WebLogic Portal 8.1 it would have to be how flexible the overall framework is with respect to accomplishing tasks that were not catered for in the original design. Since much of the framework code exists in the various folders in the /frameworks directory, changing or replacing existing behavior is often simply a matter of modifying the appropriate framework files.
The other day I was assisting someone with how to have the default page not appear in the menu. Basically they had a book called “Home” that had a default page called "Home". The standard multi level menu would render a top-level menu item for the book and then a subsequent lower level item for the Page thereby resulting in two "Home" menu items. What they wanted was to simply have one menu item called "Home" that when clicked would go to the book’s default page.
The obvious solution would be to make the page hidden, however this has an undesired effect in their case. When a book’s default page is hidden, navigating to the book will cause the next non-hidden page to be displayed rather then the default hidden page. This feature is either a benefit or a hindrance depending on what you want to accomplish, in this case it was a hindrance unfortunately.
We discussed a couple of different solutions and came up with two options as follows:
1. Modify the menu code to not generate menu items for default pages; or
2. Modify the menu code so that even when a default page is hidden, clicking on a book will navigate to that page correctly.
The solution that was chosen was option 2 since it was felt that there might be cases where the default page should be shown as a menu item and creating a configuration scheme to handle exceptions would make option 1 more complex to implement.
Implementing option 2 was relatively straightforward; we merely altered submenu.jsp to generate a URL that pointed directly to the default page of a book instead of the book itself. You can still navigate to a hidden page if the URL is explicitly targeting that page, so this fix takes advantage of that behavior to accomplish the goal.
Unfortunately there was one edge case where this could not be made to work. The default page of the portal's default book could be considered the portal's default page since when we access the portal by the root URL it is this page to which the user is directed. If this portal default page is hidden, navigating to the portal’s root URL will cause the user to be directed to the default book’s next non-hidden page. Since this behavior occurs in the portal servlet, it is not something that we can easily modify.
For this edge case, we had to use option 1. Thus we modified the menu code so that it would not generate a menu entry for the portal’s default page but option 2 was used in all other places.
The amount of code to do this was quite small and easy to apply. Thanks to the flexibility in the framework we were able to deliver a requirement that had not been catered for in the original portal design.