Martin Desruisseaux wrote: > Jody Garnett a écrit : >> So here is what we need to do: >> - We need to make sure all the FactoryFinders use the same >> FactoryRegistry > If global 'addFactoryIterator' is the only rational, a singleton > FactoryRegistry is one possible approach but is not required. The list > of FactoryIterator don't need to be a field of FactoryRegistry. I don't mind where it goes as long as some one class takes responsibility for holding our global configuration. I do not want to hunt down all bits and pieces from all of the library. And I would like to ensure that modules that come later are able to play. > I started code for that. Will try to commit when I will have a chance > (I was away today). I can review. >> The class that should be called "RegistryFactoryFinder" is really >> only for the registry module: >> - It is not aimed for users! (It is for the registry module's own use) >> - If a module like unsupported/geometry needed to create content it >> should make its own GeometryFactoryFinder that gathers together the >> resources it needs (reuse of FactoryFinders is bad) > What is RegistryFactoryFinder? Sorry my type mumble - In our discussion yesterday you said that FactoryFinder was only really for the referencing module. So it should be called ReferencingFactoryFinder.
The direction of value is for a user (with their own EPSGAuthorityFactory) to teach the referencing module about the instance they have set up. The user is free to do their own thing, and indeed other modules are free to have their own FactoryFinders ... they may not always cascade from CommonFactoryFinder to ReferencingFactoryFinder. > If we are talking about CommonFactoryFinder or > referencing.FactoryFinder, then this is currently quite the opposite: > they are intented for users, not module maintainers. FactoryRegistry > is the internal class to hide to users. Darn. I find them to be very specific - Referencing Module focuses only on the referencing module - and used to hook the referencing module up to your existing application. Having a user use 5 factory finder instances in order to do a simple task is not something I encourage .. which is why I try to use GeoTools in a container. Martin can you review Justins work on the XML parser - it will show some really basic use of a container that may put us on the same footing. > referencing.FactoryFinder (for example) is not about dependencies > required for internal org.geotools.referencing (I realize that I said > that in yesterday IRC, but it was not my mind). > referencing.FactoryFinder is about exposing org.geotools.referencing > implementation to users. I see. Right now it *does* seem to: a) be pulling double duty (both as an application configuring geotools and geotools creating content for your application) b) be configured by your application - currently with classpath jars and ordering hints c) be used internally by other geotools modules d) used by an application to create geotools artifacts I frankly have problems with every one of these issues. I don't have to solve them this week however :-) Jody PS. I will need to solve some of them this month (so our conversations will come to an end) ------------------------------------------------------------------------- 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
