Bug 697850 - Child Resources subtab refreshes twice
Child Resources subtab refreshes twice
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.0.0.Beta1
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks: jon3-sprint1 715334
  Show dependency treegraph
 
Reported: 2011-04-19 08:58 EDT by John Mazzitelli
Modified: 2013-09-03 12:57 EDT (History)
3 users (show)

See Also:
Fixed In Version: 4.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-03 12:57:00 EDT
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 John Mazzitelli 2011-04-19 08:58:14 EDT
Go to any resource that has children. Specifically navigate to its Inventory > ChildResources subtab and notice the table refreshes twice in quick succession.

We don't want to refresh or load the table twice everytime we go to the child resources page.
Comment 1 Jay Shaughnessy 2011-04-20 09:12:27 EDT
I'm not sure there are really two loads here.

When switching subtabs I only see one call to fetch the children (findResourceCompositesByCriteria()).  When navigating directly (via, say, the back button or a browser url when not currently in the resource detail view) there are in fact two calls to findResourceCompositesByCriteria(). But, this is expected.  We always call findResourceCompositesByCriteria() when loading a resource detail view, that call loads the target resource.  The second call then loads the children.
Comment 2 Jay Shaughnessy 2011-04-20 17:42:43 EDT
paraphrased from mazz: "the issue is a visible redraw of the list grid contents. Whether or not this is tied to an unnecessary db fetch is not known. The spinner spins, though.  But, at last try it did not reproduce."

I suggest we drop prio on this and move to jon3 from rhq4.  Stopping work for now.
Comment 3 Charles Crouch 2011-04-25 11:48:33 EDT
Unassigning as work is stopped
Comment 4 Ian Springer 2011-05-17 16:33:17 EDT
Note, this issue actually affects all subtabs (or all that implement RefreshableView, which may be all of them). There is a separate BZ for the same issue on the Configuration>Current subtab (https://bugzilla.redhat.com/show_bug.cgi?id=704742), which is a bit different than most subtabs, because it is not a Table.
Comment 5 Jay Shaughnessy 2011-05-19 09:53:22 EDT
commit ecd63ba59b3e985481dc76de3044dfad656a8dd2
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Wed May 18 15:22:25 2011 -0400

For the resource and group detail views (The two level tab views) ensure
that for RefreshableViews the subtab canvas is not rendered until after
refresh() is called on the canvas.  This allows the refresh method to
clear stale data from an existing canvas before initiating the async pull
of new data, preventing the user from briefly seeing the stale data and
then having the refresh kick in (which can look a lot like an unnecessary
refresh)

For Tables this works well without any changes to the refresh() method.
That's because the ds invalidateCache method clears the grid. Other
views may have to ensure the canvas is presentable in the refresh impl.
This commit includes a change like this for the current resource config view.
Note that the other 3 config views (resPlugin, groupPlugin, groupConf)
already handled this as needed.
Comment 6 Mike Foley 2011-05-24 16:01:18 EDT
verified.
Comment 7 Heiko W. Rupp 2013-09-03 12:57:00 EDT
Bulk closing of old issues that are in VERIFIED state.

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