[Dev] Tool categories

[Ryan Kruse]

Maybe these top level categories should be real buttons in the new flex UI too.  Having our "Tools" menu seems kind of like development speak to me.  I user would like to display some stuff, run a live poller or make some changes.  Users don't need to know that the Tool Plugin framework is behind all of them.  Discuss.


________________________________
From: dev-bounces at ziptie.org [mailto:dev-bounces at ziptie.org] On Behalf Of Ryan Kruse
Sent: Wednesday, May 14, 2008 4:53 PM
To: 'ZipTie Development List'
Subject: Re: [Dev] Tool categories

I'd like to put every tool in a category for 2008.04b. See below.

 *
Change
    *
OS Push
    *
Password Change
    *
SNMP Community Changes
    *
Syslog Setup
    *
Port Enable/Disable
    *
Port VLAN Assignment
    *
NTP Setup
 *
Display
    *
Filters/ACL Model
    *
Interfaces Model
    *
VLAN Model
 *
Live
    *
Retrieve Images
    *
SNMP walk the system tree
    *
OS Fingerprint
    *
Traceroute
    *
Ping

Additionally I don't want to build categories for device types, e.g. Cisco.  The tool filter should take out the tool if it isn't applicable.  The user can rely on it showing up as an indication that it will work on that device selection.


________________________________
From: dev-bounces at ziptie.org [mailto:dev-bounces at ziptie.org] On Behalf Of Brett Wooldridge
Sent: Wednesday, May 14, 2008 7:09 AM
To: ZipTie Development List
Subject: [Dev] Tool categories

Team,

I have added support for nested tool categories so that tools can be grouped under the submenu in an arbitrary fashion.  The category that a tool resides in is controlled by the new property 'tool.category'.  It works like this:

tool.category=Cisco,IOS

If a tool has this property then under the UI 'Tools' right-click menu would be a submenu called 'Cisco', and a submenu under that called 'IOS', and under that the tool itself.  I just used this example to illustrate that it can be nested.  However, I recommend that we stick to one subcategory deep at this time.  If you play around with it you'll see what I mean, it is not very nice to navigate a deep hierarchy to find a tool.

If there is no 'tool.category' property the tool appears directly under the 'Tools' menu, as it does now.  My recommendation is that unless a tool is specific to a category, we leave it at the 'top' (i.e. Ping, Traceroute, etc.) and only use categories when it declutters the top-level menu.  But we should resist the urge to create a 'General' category and start throwing tools in it.

What we do in terms of categories will affect how other tool authors categorize their tools, so let's keep it simple. I think if a vendor has more than one specific tool (IOS Password Change, IOS Software Distribution) it might warrant a category.  In this case I would stick with 'Cisco', rather than 'Cisco'->'IOS' or even 'Cisco IOS'.  Only when the Cisco category gets too full or confusing should another level be added or the tools recategorized.

I updated the test.properties file, so the test tool now lives in a deep category hierarchy (to exercise the framework and to serve as an example of why deep categories suck).

Ryan, you might want to go through and categorize the tools you think need their own submenu.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080514/9c5aaaa3/attachment.html