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 -> [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
