As part of the requirements for resource clustering (see below link) a piece of screen real estate needs to be cordoned off to make room for the new hierarchical navigational component. Up until now, we've been able to get away with having other navigational elements (tabs, overall layout, error handling tidbits, etc) duplicated in each web technology - one in Struts, and one in JSF.

Even though writing a hierarchical navigation component (with rich features like right-click context menus, icon overlays, ajax data loading) in Richfaces/JSF is rather straight-forward, repeating that functionality in Struts is not. So, by *not* writing this navigational element in both web technologies, we need to change how we go about structuring the page layout. So instead of having duplicate navigation elements, we are finally going to convert the rest of the user interface to pure JSF. There are two ways we could do this:

1) JSF would be the "outer" container, which would embed existing Struts pages inside of it. In order to do it correctly, the Struts controller needs to "merge" with the JSF controller (in some way, shape, or form). Previously one would hit a page such as "somePage.do?someParam=someValue", but that page now needs to load a JSF container page which in turns loads the Struts children tiles. This is easier said than done because there are a consider number of links and navigation rules that would need to be updated as a result of this interlace.

2) Go pure JSF. Today, there are two primary types of struts pages in the UI: full-screen and non. The full-screen pages are things like creating a new alert definition, editing metric templates, viewing a details metric chart, and editing users and roles; these pages are not affected by the new navigational component whatsoever because they were not tiled under the standard layout mechanism, thus making their links isolated from the JSF navigation rules. However, any non-full-screen page would need to be translated into pure JSF. Luckily, this includes *only* the subtabs under the monitor tab (visibility, metric data, events, timeline, configuration)

In this case, I've opted for the latter strategy. Although #1 might be a bit quicker, #2 is the direction we would eventually want to go in for purposes of consistency & maintainability. It will shrink the codebase considerably, as all of the Struts-based navigation / layout elements will be obsolete.

-----

http://support.rhq-project.org/display/RHQ/Design-ResourceClustering