all two-level tab navigation was broken

Ian Springer ian.springer at redhat.com
Mon Dec 13 18:08:20 UTC 2010


Sorry about that - I forgot to test detail views after I made that change.

Note, our view navigation code is currently hard to work with, because 
the ViewPath/BookmarkableView APIs are not used consistently throughout 
the app. In some places, we do:

1) View V1's renderView() impl receives a view path whose current view 
has been advanced past the view ID corresponding to V1. So it either 
points at a a child view ID or is at the end of the path (i.e. 
viewPath.isEnd() == true). AdministrationView or any other top view, or 
TableSection, are examples of this.

while in other places, we do:

2) View V1's renderView() impl receives a view path whose current view 
is pointing at the view ID corresponding to V1 itself. 
ConfigurationHistoryView or any other detail view are examples of this.

Note, in either case 1) or case 2), is is assumed V1 may need to finish 
rendering itself before rendering any descendants.

I think we need to come up with consistent semantics for this API and 
use them consistently across the app, otherwise maintaining this code is 
not going to be pleasant. Specifically, if the view ID pointer is not 
advanced in a consistent way by parent views calling renderView(), then 
renderView() impls will not know whether the current view ID represents 
themselves or a child view.

-- Ian


On 12/13/2010 09:58 AM, Joseph Marques wrote:
> Two-level tab navigation appeared to be bust this weekend.  After some
> investigation I was able to track the issue down to commit b20dc08 from
> Friday/11am (fix so subtab content refreshes when you switch back to a
> subtab BZ-661528).  That fix altered the following line:
>
> if (subView instanceof BookmarkableView) {
>
> to:
>
> if (subView instanceof BookmarkableView&&  !viewPath.isEnd()) {
>
> so that the else block, which checks for RefreshableView, would
> trigger.  The larger effect of this, however, is that renderView for
> TableSection is never invoked...not on first page load, not on tab
> switching, not on subtab switching.  This then has the effect that the
> private member variable 'basepath' for TableSection is never set, which
> means that the master/details navigation is broken (row double-click,
> name-column hyperlink, back-to-list functionality, new button, etc).
>
> So I removed the check for isEnd() and things are back to normal for
> now, but it likely reintroduces some or all of BZ-661528.  I've flipped
> that bugzilla back to ON_DEV, and reassigned to Ian to take a look at,
> but I think the bigger issue here is how easy it is to regress on a
> large part of the navigation experience when plumbing around in our
> infrastructure classes.  We either need to put some emphasis on
> automated testing in this area, or be a bit more diligent about manually
> testing for regressions when committing enhancements to these classes.
>
> -joseph
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com



More information about the rhq-devel mailing list