[udig-devel] [Geotools-devel] Catalog API backporting

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

Hi developers, hi Jody in particular

One again some questions/comments to your wiki page
http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI

Sorry I was a bit fast in my first mail. But the idea was exactly what I had in
mind.
So what I tried in the meantime was: I took the classes depicted in the UML
diagram (GeoResource, GeoResourceInfo and, since needed, IRersolve) and was
able to separate them out of uDig quite easily (to my surprise).

Actually the changes needed were:
1.) I dropped the reference to IService from IGeoResource:
    public IService parent(ProgressListener progress) throws IOException{
        return resolve(IService.class, progress);
    }
since I am not sure if IService is something that is required in GeoTools (see
below).
2.) I replaced all occurrences of "ProgressMonitor" with GeoTools'
"ProgressListener". Is it possible write an adapter between the two?

3.) In IGeoResourcInfo I replaced  SWT:ImageDescriptor with AWT:Icon. I have an
adapter between the two, so not big problem for the user.

Question to you all: Are these three mentioned classes the only ones that need
to get backported or is there immediate need to backport things like IService,
IServiceInfo or ICatalog to GeoTools as well? They make sense in uDig, but in
GeoTools?

---

In theory I could now couple these classes with my new MapFramework in two ways:
Either MapLayer would simple reference GeoResource:
  someMapLayer.getGeoResource();
This is analogue to uDig's ILayer interface method
  public IGeoResource getGeoResource()

Alternatively GeoResource could somehow get incorporated in MapLayer or MapLayer
could extend GeoResource. This latter approach would result in a call like
  someMapLayer.resolve(someClass, progress);
instead of the longer
  someMapLayer.getGeoResource().resolve(someClass, progress);

I don't see any disadvantages, but maybe you can tell me reasons why a strict
separation makes sense.
What's your opinion on that?

Anyway my idea is that with the help of your feedback I can merge the current
Catalog API classes that I separated out without many changes to the new
MapFramework to fill the missing gap there. This is important if I want to go
ahead with GeoWidgets.
Once this is done it will still be possible (and a good idea) to improve the
code, i.e. implement new metadata and/or filter concepts as described on Jody's
wiki page. (Although this will be something not in my personal focus.)

Does this make sense to you?

Matthias Basler
c9bama@xxxxxxxxxxx

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de