avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject [update][phyre] Management Console Status
Date Wed, 31 Jul 2002 21:19:55 GMT
On Monday 29 July 2002 12:17 pm, Peter Royal wrote:
> What Works Now
> --------------

Same as before, except now everything isn't hardcoded! *phew* that was a nice 

I also added a shell script to run from the command line for *nix users, and a 
batch file for win32, but i can't test that one...

You can pass in command line params to connect on startup, -h and -p, host and 
port respectively (port defaults to 1099 if not specified).

> What The Future Holds
> ---------------------
>  Now that things "kinda" work, I will be refactoring the application to
> separate the GUI from the data (per the original thread referenced above).
>  Each "level" of management will be a container. A container will consist
> of two roles, a "Navigation Bar" and multiple "Content Panels". Items on
> the "Navigation Bar" will load one of the Content Panels from the current
> container. This should allow proper separation of program data and GUI
> functions and (hopefully) turn the app into more of a data (or at least)
> config-driver app.
>  The Context made available to the container will expose the ability to set
> the current navigation panel and content panel.

This is done. 

There are two "helpers" exposed to a Container. One to set a navigation panel 
and one to set a content panel. If a Container loads a sub-container (say 
going from the root Phoenix container to the Container for a specific app), a 
Container can replace either one or both of the helpers to control where the 
nav and content for the child container go.

In practice, the Content helper is never replaced, but the Nav one is, in 
order to provide the "breadcrumb" trail of buttons to return to the root 

The containers are based around fortress at the moment. Each container should 
define a single navigation panel and multiple content panels. There are two 
types of content panels support at the moment, a Grid display and an MBean 
attribute / invoker panel (plus and custom panels, such as the configuration 
modification panel).

I was thinking it would be neat for each block to be its own subcontainer, 
loading an xconf over JMX to define it and (perhaps, if this is a good 
idea..) loading the .class files for any custom panels over the JMX wire too.

The way it is currently setup, each sub-container should be associated with an 
MBean. So for an app subcontainer, the Application MBean for the app is 
associated, and the attributes of that MBean are all made available in the 
context. What this means is that you can use the ${...} notation in the 
config for the subcontainer to substitute values from the associated mbean.


What's Next!

Simple display of block attributes, then probably the loading of a 
sub-container for a block as mentioned above. After that will probably be 
logger config at the app level, but I need to see how logkit will handle 

peter royal -> proyal@apache.org

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message