Bug 743742 - individual plugin config entries dialog slow and not correct
individual plugin config entries dialog slow and not correct
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.1
Unspecified Unspecified
urgent Severity high (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: jon30-perf
  Show dependency treegraph
 
Reported: 2011-10-05 17:20 EDT by John Mazzitelli
Modified: 2012-02-07 14:27 EST (History)
1 user (show)

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


Attachments (Terms of Use)
individual resource's plugin config entries (98.23 KB, image/jpeg)
2011-10-05 17:20 EDT, John Mazzitelli
no flags Details
proposed l&f for read-only property (11.15 KB, image/png)
2011-10-15 12:20 EDT, John Mazzitelli
no flags Details
proposed l&f for property that can be edited (13.74 KB, image/png)
2011-10-15 12:21 EDT, John Mazzitelli
no flags Details
proposed l&f for large group (44.20 KB, image/png)
2011-10-15 12:22 EDT, John Mazzitelli
no flags Details
proposed patch (37.41 KB, patch)
2011-10-16 01:49 EDT, John Mazzitelli
no flags Details | Diff

  None (edit)
Description John Mazzitelli 2011-10-05 17:20:02 EDT
Created attachment 526580 [details]
individual resource's plugin config entries

Create a large compatible group with resources that have plugin config.

go to the connection properties subtab. Click on the pencil icon to popup the dialog that shows all the individual entries.

First, notice it is really slow to popup. I do not think it is even going to the server (since it already got all the data from the server previously). I think its just slow building all the UI widgets.

Second, in my case anyway, the resource ancestry/name isn't shown on many of them - I only see the resource IDs. See the attached image.

I think we may need to redesign this dialog. Perhaps switch to a table backed with a data source that supports paging so we only load the resource ancestry information that is in view. Second, we can utilize SmartGWTs ability to edit individual cells (since this page also allows us to edit individual values).
Comment 1 John Mazzitelli 2011-10-05 17:20:37 EDT
making high priority - this should be considered a perf bug
Comment 2 John Mazzitelli 2011-10-15 12:20:21 EDT
Created attachment 528329 [details]
proposed l&f for read-only property

attached image for the proposed new editor that shows group memeber properties in read-only mode.
Comment 3 John Mazzitelli 2011-10-15 12:21:34 EDT
Created attachment 528330 [details]
proposed l&f for property that can be edited

attached image to show proposed editor that shows member properties that can be edited. includes the "set all values to" bar at the top.
Comment 4 John Mazzitelli 2011-10-15 12:22:47 EDT
Created attachment 528331 [details]
proposed l&f for large group

see attached for proposed editor that shows a large set of members. Notice the scrollbar now and the ok/cancel buttons remain fixed at bottom at all times. Now you can scroll the values without losing the top/bottom toolbars.
Comment 5 John Mazzitelli 2011-10-15 12:30:53 EDT
I added 3 images as attachments here to show the new proposed look-and-feel for the group members editor.

There is now a scrollable list grid along with a fixed ok/cancel button bar at the bottom. The buttons are now always visible, no matter how large the group is. No longer necessary to scroll all the way to the bottom to see the ok/cancel. Notice too this follows the same l&f for our other tables in the UI (with a footer bar at the bottom with ok/cancel).

Also, this should be a bit faster to render since before the number of components to build and render grew linearly with the # of group members. Now we just have a listgrid with an array of member data backing it.

Renders the "set all values to" a bit differently too - it appears in a header toolbar (but only if the property can be edited).

Finally, minor additions - there is now a maximize window button along with a close button in the window title and the minimize button is gone.

Most of this doesn't yet work functionally. I still have to do alot of refactoring work around setting up the click handlers, change handlers and in-table editors. But I wanted to get the new l&f done. None of this is checked in yet.
Comment 6 John Mazzitelli 2011-10-16 01:49:21 EDT
Created attachment 528364 [details]
proposed patch

i'm attaching a patch so I don't lose this. its checked in locally on my box only.

this works with the test page's group config editors so all appears to be working ok. still need to test with real data before committing to master.
Comment 7 John Mazzitelli 2011-10-17 17:42:55 EDT
I am going to be committing this to master soon. Here's how to test.

To ensure you test all possible configuration property types, it is suggested you use the latest version of the perftest plugin and use the all-config.xml scenario. to do this, make sure the server has the perftest plugin deployed, and when you start the agent, make sure you pass in these command line options:

-Drhq.perftest.scenario=all-config -Drhq.perftest.server-config=5

When you go to the discovery queue, you will see 5 server resources of type "server-config". Import them all and create a compatible group that contains all of these resources.

Now go to the group's Configuration tab and you will see the group configuration editor. You will notice two configuration groups - one that is labeled "Properties that are required" and one that is labeled "Properties that are optional". Both of those groups have the same properties, except the former one has required="true" (meaning you must provide a value, there will be no "unset" checkbox) and the latter as required="false" (meaning you do not have to specify a value, the unset checkbox can be checked to mean you are leaving the config property unset).

Try to edit all the different kinds of properties, from both property groups. Test that you can save the same values across all individual properties, test that you can save heterogenous values (that is, each member has a different property value), test that you can use the "apply to all" button, test the unset button. Test all types of configuration properties, like boolean, enumeration (i.e. the properties that have drop down menus), password properties, integers and floats - make sure the validators work (e.g. enter "abc" for an integer).

In short, try all UI components and try all types of properties
Comment 8 John Mazzitelli 2011-10-17 18:23:31 EDT
Comment on attachment 528364 [details]
proposed patch

the attached patch is obsolete, the real code has been committed to master
Comment 9 John Mazzitelli 2011-10-18 09:41:47 EDT
we should also test what happens when you have a group and one or more agents in that group are down.

also, what if the agents are up, but one or more of the actual resources are down.
Comment 10 Mike Foley 2012-02-07 14:27:44 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

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