So it is time to work with others, the geotools project has ported the
uDig IResolve API (for catalog), and completed it as an implementation
of the "extensible interface pattern". What does this mean? It means
that you will be able to supply a factory that can make new adapters for
existing IService and IResource handles (no more if/then/else logic).
I have several choices ...
Option 1: extend at the interface level
interface IResolve extends Resolve {...};
Option 2: extend at the implementation level
interface WFSGeoResourceImpl implements GeoResource, Resource {....};
Option 3: Bridge
class GTGeoResource implements GeoResource {
GTGeoResource(Resolve handle);
}
The API we are after is here:
-
http://javadoc.geotools.fr/2.2/org/geotools/catalog/ResolveAdapterFactory.html
-
http://javadoc.geotools.fr/2.2/org/geotools/catalog/ResolveAdapterFactoryFinder.html
There is no point in using the GeoTools API directly as it does not make
use of all the Java 5 tricks that make this a fun API for uDig, Option 1
looks to be non transparent but easy, Option depends on implementors too
much, and Option 3 is only useful if the GeoTools community
implementation over takes ours.
Cheers,
Jody
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
