geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] Reorg of Admin Console for 2.2
Date Mon, 24 Nov 2008 17:19:23 GMT
Thanks for the naming ideas for roles/tasks.  I'll work that into a post 
showing the proposed changes.

As far as making the tree collapsible, I think that's a major rework for 
a 3.0 release, as we would also want the collapsible nodes to contain 
their own page, describing what that category deals with and links to 
the child pages (I've seen other Admin Portals do this, but not sure if 
we can with Pluto without too much custom code.)


-Donald


Joe Bohn wrote:
> It would help me to see the fully populated proposal for the Navigation 
> Tree side-by-side with the existing tree.  It seems one of your primary 
> concerns here is the size of the tree and it isn't clear to me if this 
> proposal is actually reducing the size of the tree.
> 
> I think the real fix for the size issue is to make the tree collapsible. 
>  As you mention roles are the best way to eliminate the complexity for 
> an individual user and permit filtering based upon a subset of of the 
> roles for any particular user (server administrator, security 
> administrator, cluster management, etc...).  Both of those will take a 
> little longer to implement than a simple reorganization so we still need 
> to consider what to do now.
> 
> More comments in-line
> 
> 
> Donald Woods wrote:
>> Given our Console navigation tree has gotten so large and many "new" 
>> portlets were added in 2.0/2.1 without doing a proper reorg of what we 
>> had, I'm proposing the following changes as part of GERONIMO-4423, 
>> 4424, 4425 and yet to be created JIRAs:
>>
>> 1) Reorg the Server Console contents into main categories of:
>>    - Services (config/resources)
> Perhaps "Server Management" is a better title?  Services just doesn't 
> seem descriptive to me.
> 
>>      - combination of existing Server and Services portlets
>>      - contains portlets for server/service configuration
>>         info, threads, connectors, modules, jms server/resourecs, ...
>>      - future portlet to setup clustering/farming member servers
>>         and view their status would go here
>>    - Applications (app deployment and life-cycle)
> "Application Management" ?
> 
>>      - portlets to deploy/redeploy/undeploy apps/wars/ears/jars
>>      - portlets to install/uninstall and stop/start modules
>>      - porlet to install plugins (not export or server assembly)
>>      - future updates and/or new portlet to support deploy/undeploy
>>         apps to clusters/farming would go here
>>    - Security
>>      - portlets focused on users/groups, keys/ca, realms
>>    - Logging
> Why is logging so special?  I think it's fine under Server Management.
> 
>>      - portlets to configure logging and log levels
>>      - separate pages for Server, Web Access and Derby log viewers
>>    - Tools
>>      - everything in current "Debug Views" category
>>      - Plan Creator portlet
>>      - Monitoring portlet
>>      - Embedded DB portlets (renamed to Derby * to reflect true usage)
>>      - Apache HTTP portlet (for creating mod_jk configs)
>>      - Exporting plugins
>>      - Custom server assemblies
>>
>> I could see the Logging portlets as one page under Tools, as those are 
>> really runtime tools (changes don't survive a restart) for debugging 
>> server/application problems.
>>
>> I could also see the Security portlets being split between the 
>> Services and Tools categories (but really think these deserve their 
>> own category.)
> I'm fine with keeping this a unique category since security is such a 
> hot topic and we might eventually have a security administrator role 
> someday.
> 
>>
>>
>> The point, is that we need to review how the admin console is laid out 
>> and try to regroup into Java EE roles/tasks/concepts, like server 
>> config/resources, app deployment/mgmt and other tools/tasks.
> I agree that role/task organization is best.  For starters, we should 
> rename leaf (task) in the tree with a task-like name.  For example, 
> rather than "Web App WARS" it could be "Manage Web Applications (WARs)". 
>   Organization of the tasks could be by role but it might make more 
> sense by domain (Server tasks, Application tasks, Developer tasks, etc...).
> 
> 
>>
>>
>> -Donald
>>
>>
> 
> 

Mime
View raw message