[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] IService implementations
|
We have started fixing the udig catalog API in response to geotools
feedback on the metadata work done for milestone 2.
As a result we are replacing the geoapi Catalog interface,
CatalogEntries, MetadataEntity classes with something new of our own
devising.
We have included this work with the renaming of Registry to Catalog as
outlined in our milestone 2 documentation.
The replacement follows the IResource (aka "handle") example provided by
the Eclipse code base:
where a handle can:
- value objects (equals is based on value)
- define behavior for resources, but don't keep any state
- can refer to non existing resources
By using handles there is no way for client code to keep stale
information, every time you want state for a handle
you need to ask for it again.
The new set of classes are:
- ICatalog - formally registry
- IService - formally a RegistryEntry
- IGeoResource - formally a CatalogEntry (provided by DataStore or WMS).
By combing these clear names with the use of handles we hope to
integrate the previous search, metadata and creation facilities.
Many of these changes may be shared with geotools at a later date, and
several geotools developers will be joining us on this list to provide
feedback and a bit of help.
Jody
link:
http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog/src/net/refractions/udig/catalog/
