Hi Adrian, I can take care of this. I need a good tutorial for geoserver docs anyways. So I will throw this on the list of things to do.
-Justin Adrian Custer wrote: > Hey all, > > This email is an overview of the Catalog system with lots of questions. > > The Catalog+Tutorial needs some love. It's almost a great resource but > it needs some extra pointers and some reorganization. For example, it > has no overall introduction (what i have added is incomplete/wrong). > Also the "Implementing" section needs both an overview explaining the > pieces which need to be built and a modification of the skeletons which, > while they are great, need to be reorganized so we don't explain > resolve( * ) before the pieces which the method requires. > > > The lines starting with a '*)' below are questions for someone > to answer; the rest is my understanding which may be wrong, in > which case hopefully someone will comment. > > ************************************************************************* > General Issues and Questions > > > Creating each piece: > ------------------- > Catalog: > - new DefaultCatalog() > > ServiceFinder > - new DefaultServiceFinder( myCatalog ) > *) new DefaultServiceFactory( myCatalog ) What's this? > How is it different from DefaultServiceFinder? Is the > finder to get the services originally and the factory to > create the services from the catalog? > > > Service: > - via ServiceFinder.acquire(serviceURI) > *) via the catalog? Does this require the use of > Servicefactory.acquire(serviceURI) as in the Catalog > +Tutorial (see below)? Is there another way? > > GeoResource > - via ServiceFinder.acquire(resourceURI) > *) via the catalog? Does this require the use of > Servicefactory.acquire(resourceURI) as in the Catalog > +Tutorial (see below)? Is there another way? > > *) Do we implicitly recommend that the user make a singleton > Catalog? > > *) We don't use FactoryFinder and Factories to create Catalog > and ServiceFinder this module. Why not? I imagined the general > idea for the Geotools library was always to use the > FactoryFinder/Factory to easily transition to a GeoAPI setup > where the user grabbed one FactoryFinder and could eventually > get everything from that (be it Geotools or GeoAPI). > > *) Are there other approaches to the creation of these objects? > > > Populate the catalog: > -------------------- > - create the Catalog with new DefaultCatalog() > - create a ServiceFinder with new(myCatalog) > - create a List of services with > ServiceFinder.acquire(serviceURI) > - create a Service by getting the first element of the List > *) might the List ever have more than one element? > - add the service to the Catalog with Catalog.add(myService). > > > Use: > --- > Catalog > - to search through the catalog services with .search() > (see next) > *) resolve( *) ? When would this be used? > > Service > - to get a DataStore: > e.g. myService.resolve(DataStore.class) > > > GeoResource > - to get a FeatureSource/FeatureStore: > e.g. myGeoResource.resolve(FeatureSource.class) > - to get the Service parent and use that to get a > DataStore. > e.g. myService = myGeoResource.parent(); > myService.resolve(DataStore.class) > > *) Are those the general idea? > > > Searching: > --------- > > I presume searching is only on the resources obtainable from services > contained in the Catalog. That is, search is not against any resources > on the internet, nor against resources hard coded in the Geotools > library's code, but against entries in the services which the user has > added to their Catalog. > > *) Is that correct? > > Search is presumably against the strings contained in the > GetCapabilities documents, in the shapefiles or in the GML. > > *) Is there anywhere an indication of what is being searched within the > different service types? > > ************************************************************************ > Questions from the Catalog+Tutorial sections: > > > Using the Catalog > ----------------- > Populating the Catalog > > First code block: > > *) Why don't we iterate through the list instead > of getting only the first element? > I would expect while list.hasNext() or > some such loop. Is there only ever a > single service returned? > > Second code block: > > *) How can the hash map have three identical > keys? > I don't understand why we can reuse the > same key, 'WFSDataStoreFactory.URL.key', > each time in the hash map. Should not > this be > 'DataStoreFactorySpi.Param.PASSWORD' and > its ilk? > > Looking up Services and Resources in the Catalog > > First code block: > > *) Should factory be finder? > We just got the List of services from a > ServiceFinder object above. Have we > really switched to a factory? What kind > of factory, a DefaultServiceFactory? > What's the difference? > > Third code block: > > *) The Resource should be GeoResource, correct? > Since there's no Resource in the Gt > 2.2.0 API. > > > Implementing Catalog Support: > ---------------------------- > Implementing the Service > > The canResolve(Class) code block: > > *) Why does canResolve(null) return false when > the first statement in resolve( * ) is a > perfectly good return of null? The Resolve > *will* resolve null to null. Not that it's > interesting. > > *) What does canResolve() tell you? It's only > telling you that if the internet weather is > right you *might* be able to get a class of the > kind you request, not that you *will* be able to > resolve() the object when you request for it, > correct? That is, your resolve() call could > still fail due to i/o, right? If so, what's the > defensive programming here? > > Okay, enough for now (don't you agree). Thanks for any comments you may > have. Cheers, > --adrian > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:1004,4516fad1306821527717022! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
