Red Hat Bugzilla – Bug 743742
individual plugin config entries dialog slow and not correct
Last modified: 2012-02-07 14:27:44 EST
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).
making high priority - this should be considered a perf bug
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.
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.
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.
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.
Created attachment 528364 [details]
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.
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:
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 on attachment 528364 [details]
the attached patch is obsolete, the real code has been committed to master
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.
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE