Bug 534227 - (RHQ-1043) navigation refactoring
navigation refactoring
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Inventory (Show other bugs)
1.2
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
http://jira.rhq-project.org/browse/RH...
: Task
Depends On: RHQ-1044 RHQ-1045 RHQ-1046 RHQ-1047 RHQ-1048 RHQ-1049 RHQ-1050 RHQ-1051 RHQ-1052 RHQ-1053 RHQ-1054 RHQ-1215 RHQ-1241 RHQ-1242 RHQ-1248 RHQ-1249 RHQ-1250 RHQ-1252 RHQ-1420 RHQ-1462 RHQ-1467 RHQ-1513
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-04 13:12 EST by Joseph Marques
Modified: 2009-11-10 16:22 EST (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2008-11-04 13:12:00 EST
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
Comment 1 Joseph Marques 2009-03-09 09:12:09 EDT
closing this task since all initial subtasks for navigation refactoring are finally complete.  bugs can be opened separately, and needn't be filed under this parent issue.
Comment 2 Red Hat Bugzilla 2009-11-10 15:22:39 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1043
This bug incorporates RHQ-1267

Note You need to log in before you can comment on or make changes to this bug.