Package org.vfny.geoserver.config

Configuration Model being edited.

See:
Description

Class Summary

AttributeTypeInfoConfig	Allows editing of AttributeTypeInfo.
CatalogTest	CatalogTest purpose.
ConfigPlugIn	ConfigPlugIn purpose.
ConfigRequests	Utility methods for locatating Config classes in the Servlet context.
ContactConfig	Represents a Contact (or Party).
ContactTest	ContactTest purpose.
DataConfig	Data purpose.
DataStoreConfig	DataStoreInfo purpose.
DataStoreTest	DataStoreTest purpose.
FeatureTest	FeatureTest purpose.
FeatureTypeConfig	FeatureTypeInfo purpose.
GlobalConfig	Global GeoServer Configuration model.
GlobalTest	GlobalTest purpose.
NameSpaceConfig	NameSpaceConfig purpose.
NameSpaceTest	NameSpaceTest purpose.
ServiceConfig	ServiceConfig purpose.
ServiceTest	ServiceTest purpose.
StyleConfig	StyleConfig purpose.
StyleTest	StyleTest purpose.
ValidationTest	ValidationTest purpose.
WFSConfig	WFS purpose.
WFSTest	WFSTest purpose.
WMSConfig	WMS purpose.
WMSTest	WFSTest purpose.

Package org.vfny.geoserver.config Description

Configuration Model being edited.

This class opperates as the Configuration Model and is stored in Web Container.

Details:

• Represents the Model of the STRUTS based Model-View-Controller Design
• Will support additional user-interface state, beyond requirements of the GeoServer application.
• Makes use of GeoTools2 Catalog/DataStore for FeatureType type names and FeatureType schema information/generation.
• To access live content, use the DataConfig.findDataStore()

Of the course of sorting this stuff out we have had a couple of bad ideas:

• It is tempting to replace a lot of these classes by changing the scope of the FormBeans to session, rather than request. I cannot convince my self that this would be a good idea, as storing the configuration model (and associated resources in the Web Container) is sure to prevent duplication in the face of multiple users configuring differnt subsystems. If the state was limited to session - they would manage to overwrite each other with no prior warning.
• It is tempting to make the Actions use the DTO objects directly (or forgo the config classes entierly). Having the config classes allows us to make whatever methods we need for easy, quick ui developement without breaking the rest of the application.