avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject [phyre] Management Console Status
Date Mon, 29 Jul 2002 16:17:37 GMT
As the observant (and subscribed to avalon-cvs) members may have noticed, I 
checked in a first, very-rough, cut of a swing management console for 
phoenix. It is available at 
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-apps/phyre/

I have followed the general GUI patterns layed out by Peter Donald in the 
following message:
http://marc.theaimsgroup.com/?l=avalon-dev&m=100666024311393&w=2

I believe his ideas in there hold true and will be roughly following them.

             -o-

What Works Now
--------------

 First, you need to be using the MX4JSystemManager in phoenix, and pass in the 
"enable-rmi-adaptor" configuration option with a value of true.

 You can then run phyre. Currently, it will attempt to connect to 
rmi://localhost:1099 upon startup, mainly to make my life easy during 
development. There is a File->Connect menu option available to connect to an 
alternate host/port.

 When it starts you will see a *VERY UGLY* looking screen. The two buttons at 
the bottom to restart phoenix work, if you feel so inclined.

 You can also click on "Hosted Applications" to see a list of applications 
currently running inside of phoenix. If you double-click on an entry in the 
grid you will drop down one context level and be modifying that application. 

 On the main application info screen the buttons for Stop and Restart work. If 
an app is stopped you don't get a start button though :)

 You can then click "Configuration" to see a list of the blocks and whether or 
not there is currently any configuration information for them. If you 
double-click on a block that has configuration information, you will get a 
testbox with the XML representation of that Configuration.

 If you have schemas for your blocks and are using a ConfigurationValidator, 
you can hit "Validate" and validate your configuration.

 Otherwise you can modify the configuration and hit "Update" and the 
configuration will be stored in the ConfigurationRepository.

 If you are using the FileSystemPersistentConfigurationRepository, when you 
modify the configuration via the GUI, the changes between your active 
configuration and the configuration that was stored in the SAR are persisted 
to disk, and will be used next time Phoenix is started up.


            -o-

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 what I will be working on next (ie when I finish this email and eat 
lunch).

 For forms, I am looking at the Luxor XUL package 
(http://luxor-xul.sourceforge.net/index.html).

 It looks really neat, but it is GPL licensed. Is that okay to use from an 
Apache-licensed project if we are only using the binaries, not making 
modifications to the Luxor source? One of the things I want to do is enable 
the creation of a config modification screen for blocks but base it off the 
schema. Since the schema will (most likely) be an XML document, if forms can 
be represented as XML, I can write an XSLT to write forms from a schema! I 
hate reinventing the wheel.

 The other choice is Xybris 
(http://www.jbrix.org/kits/xybrix/updates/2002-03-17.html) but it doesn't 
appear to be under very active development. It is MIT licensed though which 
(may) be more compatible with the APL.

back to work!
-pete

-- 
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>


Mime
View raw message