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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com