On 10/23/2010 12:05 PM, John Mazzitelli wrote:
...
1) the new Administration>Templates GWT based GUI (it shows essentially
the same data as the old jsp templates page, but in scrollable lists
views - the servers are in a tree view with the tree nodes collapsible
under all top level servers).
...
Anyone knowledgeable in the way the old jsp pages work for alert
templates, please look at this new stuff to make sure I didn't forget
anything.
Yeah, the type hierarchy certainly complicates the issue. There are
three main "buckets" of types that I can see:
1) types with multiple parent(Type)s
2) types with precisely one parent(Type)
3) types with no parent(Type)s, which is a special case of #1 because it
implies all possible parent types
I've installed all plugins available in the RHQ repo, then did a quick
analysis (see attachment) to help those reading this thread get familiar
with these various relationships using actual types.
Although these 3 buckets naturally prevent a single resource type tree
from being the main entry point into administration>templates, we
shouldn't force the user to understand these different buckets /
relationships when exploring the templates page to find the type they
want to create a template against.
In the old JSP pages, although these 3 buckets did exist, they were all
auto-expanded by default. This allowed the user to ctrl+F (find),
iterate through the results, and find the name of the type they were
looking for. The new UI takes away that ability because the server type
trees are collapsed, making it more difficult for users to quickly find
the type they are looking for. For instance, I can no longer ctrl+F,
enter "jvm" and find the various jvm types to create alerts against.
My suggestion would be to use a single, flat list view with one or more
search filters at the top (name filter, category filter, etc). The
immediate result (assuming the default sort is alphabetical on the name)
is that the row items might look like:
Connector
Connector
Embedded Tomcat Server
Embedded Tomcat Server
Here, the "Embedded Tomcat Server" rows are the names of a resource
types that exists as children servers under two different "JBossAS
Server" resource types, one defined by the JBossAS plugin, the other by
the JBossAS5 plugin. Likewise, the "Connector" rows are the names of
the service resource types that exists under the parent "Embedded Tomcat
Server", but since there are two distinct parent(Type)s, there are two
distinct children with the same name.
Although this seems like an issue on the surface, we do have experience
in dealing with problems of this kind -- disambiguation. If we simply
augment the list to show disambiguated resource type info, then a
single, flat list view should suffice. Users can quickly search it (by
type name, by type category, etc), and for types that have name
duplicates the corresponding hierarchy is there to disambiguate:
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS5)
Embedded Tomcat Server : JBossAS Server (JBossAS)
Embedded Tomcat Server : JBossAS Server (JBossAS5)
Then, for the special case where resources either don't have a parent
(typically platforms [which are logical root types] and servers [which
are generally discoverable under any platform]), we wouldn't even need
to add disambiguation data because they are already logical singleton
types. Below is a larger snapshot of the single, flat list view concept
with a blend of platforms, platform-services, top-level servers, nested
servers, and services all in one:
AIX
Ant Bundle Handlers
Cobbler
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS5)
CPU
Embedded Tomcat Server : JBossAS Server (JBossAS)
Embedded Tomcat Server : JBossAS Server (JBossAS5)
File System
File Template Bundle Handler
FreeBSD
Hosts File
HP-UX
JBossAS Server (JBossAS)
JBossAS Server (JBossAS5)
Linux
Mac OS X
Network Adapter
Process
Solaris
Sudoers
Windows
Last but not least, we should have a checkbox at the top of the table to
filter by "utilized types". Utilized types are the types in the system
that have at least one resource instance in inventory. This (often
dramatically) reduces the number of displayed types. For instance, if
I'm a RHEL/EAP shop and haven't yet upgraded to EAP5, my utilized type
list would look like:
Ant Bundle Handlers
Cobbler
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
CPU
Embedded Tomcat Server : JBossAS Server (JBossAS)
File System
File Template Bundle Handler
Hosts File
JBossAS Server (JBossAS)
Linux
Network Adapter
Process
Sudoers
The disambiguation information is still there (it doesn't hurt to show
it, even when it's unnecessary), but the results are a lot more focused
because resource types the user may never need are suppressed.
Thoughts?
-joseph
PS - The "HTTPService" and "PingService" are not listed anywhere in
any
of the 3 existing buckets, either on the old JSP pages or the new
GWT-based, scrollable list views. Although they are logically
platform-services, they were defined in a separate NetworkServices
plugin (not defined by the platform plugin). The single, flat view list
concept would not treat these edge cases any differently, and would
display them in the results without issue.