Jody Garnett ha scritto:
> We do have getInfo() which we can add to. I would prefer to use an
> open end Map/Key combo until we settle down on what is needed (much
> like how we treat Parameter.metadata right now.
Oh no, not another map. Building the datastores by creating a
map is painful enough already.
A capabilities bean as a concrete class that stores can subclass
should be much better.
I honestly never used getInfo() but it seems to be related to GUI
concerns (despite of what the DataAccess javadoc says about filter
capabilities, all I see is titles, icons, keywords),
mixing actual usage capabilities seems a way to confuse matters.
I prefer an explicit Capabilities() method that returns
a SchemaCapabilities object where SchemaCapabilities is a class
just like QueryCapabilities:
public class SchemaCapabilities {
boolean supportsDrop(Name name) {
return false;
}
boolean supportsCreate(FeatureType featureType) {
return false;
}
boolean supportsUpdate(Name name, FeatureType featureType) {
return false;
}
}
The thing I'm not convinced about in the above:
- it forces the qualified names into the simpler DataStore API....
- not sure if we want to pass the FeatureType as a parameter
in supportsCreate and supportsUpdate, maybe they should just be:
supportsUpdate(Name) and supportsCreate()
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
