It seems we are going around in circles here a bit ... I am sorry I do not have time to participate more fully right now. I agree that both approaches can live together (we produced a sample code example at FOSS4G that I emailed the list), and hope to take a more active roll when I get near code again.
We seem to have slightly needs (or users) in mind resulting in a bit of confusion. Lets agree on terms first: - developers - developers contributing to (or working on) a geotools plugin like a datastore - users - someone using the tool kit in an application #1 Functionality and Consistency USERS I would like to see users be able to set up a Datastore on a per query basis to do what they want to. For any factory used by geotools I want them to be able to supply their own. The test: producing plain old java objects (implementing Feature interface) from a shapefile datastore DEVELOPERS I would like to ensure they support constructor (and against everyones wishes setter) injection for every factory they make use of. Since factories "cascade" this is not usually a large amount of work, I just want the code to be honest about what it does. As an example many Style transformations also produce expressions, as such they need to take an FilterFactory - but during the 2.2.x QA checks I found that they mostly cheated the system. This is what is needed to make the library function, and be consistent. Until we have this I cannot really start on step number two.... #2 Usability The next question is how to make this easy to use for users, and easy to develop for developers? USERS Setting up some global switches so users can change some basic defaults (use of a feature factory by default, or default use of a specific epsg authority). This lets us handle the default problem fairly well, and will work fine. For injection (if the user actually does that, which geoserver and udig are wanting to) they can use a third party solution like Pico Container or Spring. Being able to use a third party solution, and behave in the way users expect, is why go with injection. DEVELOPERS Being able to look up a default implementation that meets their needs (the CRS factory enforcing longitude/latitude order is a fine example). So we have several tools on the table: - Factory / Interface split - we need to ensure GeoTools always does this - Factory Injection - Hints - Ability to look up Factory instances - we need to break out the lookup system for SPI / Spring / Equinox - FactoryFinder So here is my question - how do we define the relationship between Map hints, looking up defaults, and factory finder. Do we have two different APIs? One for Users and one for Developers? This is the section where I think our communication is getting lost, ... So let me try a list (I was hoping for Justin's help on this): - I would like to ensure that we move the factory finder interfaces we have now out into an extension (I think justin already started?) - And that our developers do not make use of them at all - I would like to make sure our factories work with injection We then have a trade off: One big FactoryFinder for "defaults": - visible to client code giving them one stop shoping for any geotools construct - with new FactoryFinder( Map hints ).create( Class factory ) - would process the extension - this really just looks like a poor mans container which is why I am worried we are reinventing a computer science wheel rather then focusing on geospatial stuff - has the advantage that Factory instances are still straightforward to develop (either with hints or injection) Factory supplied "defaults": - process is not user visible, they get geotools constructs via "new" or via their container - the factory knows what it is setting up and can be sure to find the appropriate content (can make use of user supplied defaults if needed) - developer is responsible - user can use injection to override and take control Later, Jody > Jody Garnett a écrit : >> - deprecate *all* factory finder methods and place them in an ext/ so >> that our code is forced to use injection > > Deprecating factory finders was not my plan... Style and Filter > factory finders are not implemented as they should be. But referencing > factory finder (for example) should fit the needs - it already cover > non-trivial hints cases. > > "FactoryFinder.getFooFactory(hints)" or "new FooFactory(hints)" can be > see as kinds of constructor injection. Factory dependencies are > specified as a map of hints instead of explicit argument, but in both > cases they are processed at construction time. > > Cons: > * Supported hints are not visible from an API point of view. > User needs to read the javadoc. > > * Hints are not supported by picocontainer and similar. > > Pros: > * User specifies all the hints he care about (and only the hints he > care > about), no matter if it is supported by the Factory or not. The > factory > will pickup the relevant hints from the map. For example the user > may set > a COVERAGE_PROCESSOR hint. CRSFactory will ignores this hint, but > other > factories may use it. User can just specify all his need once > without the > need to adapt his request on a factory-by-factory basis. > > * A Map is extensible, while constructor arguments are not > extensible without > a compatibility break. If a new dependency is introduced in future > factory > version, adding an argument to the constructor requires at least a > deprecate > - remove release cycle and requires updating every methods that > invoke this > constructor. Using a Map, we can process with no API change. > > * Hints provide some flexibility not available with constructor or > method > injection. Again, how can we said "any CRS factory enforcing > (longitude, > latitude) axis order" with constructor/method injection? > > > Actually both approachs: > > - Constructor(Hints) > - Constructor(Factory1, Factory2...) > > can probably live together in most cases. So doing one approach do not > exclude the other. > > Martin ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
