As Chris mentioned earlier we will have an irc about user interfaces in a little bit.
Our current system combines three functions:
- reading in the xml files
- holding the configuration information
- data binding for the application
I would much rather have a separate in memory configuration model that would could code our user interface against.
What I have figured out so far:
- we are not commited to using struts (apparently we just have the jar for historical reasons)
The only advantage I could see to using struts would be that it would force us to keep a nice model-view-controller separation. The downside is that it would be yet another thing to learn.
A quick walk through the code reveals the following information being maintained by the configuration process: ( I am sure I have missed some but it is a starting point)
ServerConfig:
* root directory
GlobalConfig:
* global.maxFeatures: int (default 2000 )
* global.level: Level (default same as org.vfny.geoserver)
* global.verbose: boolean (default true)
* global.numDecimals: int (default 8)
* global.base: URL (default httpd:/localhost:8080/)
* global.schemaBase (default httpd:/localhost:8080/schema)
* global.charset: Charset (default ISO-8859-1)
Catalog Config: (this appears to almost "be" the application - holds live data connections)
* namespace.uri: String
* namespace.default: boolean (default false, true if only one namespace)
* datastore.id: String
* datastore.enabled: boolean (default true)
* datastore.title: String
* datastore.abstract: String
* datastore.featuretype.srid: int (default 0)
* datastore.featuretype.numDecimals: int (default 8)
* datastore.featuretype.bbox: Envelope (default calcuated)
WMS Config:
* exception formats
* fixed service name
* update time
* wms version
WFS Config:
* fescribeURL
* WFS Basic LOC
* WFS CAP LOC
* WFS Folder
Common to WMS and WFS:
* enabled
* onlineResource
* serviceType
* URL
* abstract
* access Constraints
* fees
* keywords
* maintainer
* name
* title
Validation Config:
* Validation Plug-Ins - xml file for each Validation Java Bean
o validation.plugIn: Bean (Class required )
o validation.plugIn.description: (String optional )
o validation.plugIn.defaults: (Map optional )
* Directory of XML based validation tests
o tests: List of tests
o tests.test: plugIn (String required)
o tests.test.description: definition (Map optional)