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
exercise.
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
container.
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.
-o-
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
that.
-pete
--
peter royal -> [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
