Bug 697850 - Child Resources subtab refreshes twice
Summary: Child Resources subtab refreshes twice
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.0.Beta1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon3-sprint1 715334
TreeView+ depends on / blocked
 
Reported: 2011-04-19 12:58 UTC by John Mazzitelli
Modified: 2013-09-03 16:57 UTC (History)
3 users (show)

Fixed In Version: 4.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-03 16:57:00 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 704742 0 medium CLOSED when returning to Configuration>Current tab, the original config editor is shown for a few seconds while a new/refreshed... 2021-02-22 00:41:40 UTC

Internal Links: 704742

Description John Mazzitelli 2011-04-19 12:58:14 UTC
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 13:12:27 UTC
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 21:42:43 UTC
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 15:48:33 UTC
Unassigning as work is stopped

Comment 4 Ian Springer 2011-05-17 20:33:17 UTC
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 13:53:22 UTC
commit ecd63ba59b3e985481dc76de3044dfad656a8dd2
Author: Jay Shaughnessy <jshaughn>
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 20:01:18 UTC
verified.

Comment 7 Heiko W. Rupp 2013-09-03 16:57:00 UTC
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.