Hi Gabriel - a couple of thoughts .... I am a bit worried about the mixing of factory code and logic.
Aside: In this case you are trying to stick additional context into the creation process ... that smacks of logic to me? FilterFactory is supposed to be stupid. An option would be to add the configuration step to a FilterBuilder using normal injection (the FilterBuilder would be constructed with your prefix mappings and a filter factory). That said if FilterFactory needs that additional information in order to function you will need to create a new hint, you can still do normal constructor/setter injection which will be useful when writing test cases and so on. For the DataStoreFactory you should already be covered; there is a common factory finder that should have a method to return the current GeometryFactory. The GeometryFactory you want to use can be set as the GeoTools getDefaultHints(). For the harder case of changing the GeometryFactory used on a query by query basis we will need to talk in more detail later. You are correct that our implementation of environment variable stuff is incomplete ... it is more a tool for those writing expressions (and SLD files), rather than what you are looking for (I think). Gabriel Roldán wrote: > Thanks Jody, > > so the next step is to know if that use of Hints is correct or not. Martin > can > you confirm? > > Sample scenarios: > - Using Hints to pass "context" to a factory. Case being passing a set of > prefix:namespace mappings to FilterFactory in order to make it namespace > aware. As the prefixes mappings may change from invocation to invocation, it > makes no sense to cache the factory instance. Case being WFS requests using > different prefixes to refer to the same namespaces. > > - Using Hints to pass a given GeometryFactory instance to a DataStoreFactory. > Rationale being client code wanting to use geometry factory configured a > given way, as to use a given precision model, coordseq factory or even pass a > factory that produces geometries which already implement GeneralPath or > whatever needed to directly render them without further conversion. > > I've took a look at the environment variables stuff, and imho it seems in a > far early stage than the Hints system and even more, it seems to me too > tricky or I just can't make a good sense of how they would work in > the "namespace context" case. > > Gabriel > > On Wednesday 23 May 2007 18:59:05 Jody Garnett wrote: > >> The Hint system was only recently hooked up - and I found a few problems >> with it during that process. Please assume that any troubles you have >> are just a QA problem (and something you can fix; and have permission to >> fix). >> >> For anything to do with runtime evaluation of filters you should look >> into the environmental variable part of the specification; and think >> about how we can make use of this ... My best idea is to make a utility >> function can can be used with a Map to resolve all the environmental >> variables in an expression to literals. >> >> Jody >> >> >>> btw, >>> If I want to pass hints to FilterFactory, does it necessarly needs to >>> declare which ones it accepts through getImplementationHints()? >>> >>> I ask because I'm looking at GridCoverageFactory and, thgough it can >>> handle some hints at its constructor, it just returns an empty map in >>> getImplementationHints (inherited from AbstractFactory). >>> >>> But if I do the same in FilterFactoryImpl, the hints are never passed, >>> seems an instance preiously created without hints were cached somehow and >>> after that the constructor that expects Hints gets never called, even if >>> I pass an actual Hints to CommonFactoryFinder.getFilterFactory(Hints). >>> >>> Is that correct? are they actually behaving differently? am I just not >>> making sense of all this? >>> >>> cheers, >>> >>> Gabriel >>> >>> On Wednesday 23 May 2007 14:25:36 Gabriel Roldán wrote: >>> >>>> Hi Justin, >>>> >>>> I was trying to imeplement a namespace aware property accessor to work >>>> with AttributeExpressionImpl, and got a bit confused on the use of >>>> Hints. >>>> >>>> I could achieve the same result I'm looking for by hacking my own >>>> FilterFactory implementation that creates namespace aware PropertyName >>>> expressions, but would like to make my mind clear about the following >>>> issue first: >>>> >>>> PropertyAccessorFactory.createPropertyAccessor(...) receives a Hints. >>>> It is only called by PropertyAccessors.findPropertyAccessor, which >>>> should pass the Hints to PropertyAccessorFactory.createPropertyAccessor. >>>> In turn, PropertyAccessors.findPropertyAccessor gets called by >>>> AttributeExpressionImpl.evaluate(Object), but allways passes null in >>>> place of Hints. >>>> So the question is, how do I actually pass some hints to >>>> PropertyAccessors.findPropertyAccessor ? >>>> >>>> If it is just an unfinished edge of the thing, I wonder if the following >>>> would be correct: >>>> - Add a constructor to AttributeExpressionImpl that receives a Hints. >>>> - Make FilterFactoryImpl pass the Hints it receives in its constructor >>>> to the AttributeExpressionImpl it creates. >>>> >>>> I guess I'm making something very wrong, as the above approach wouldn't >>>> work neither, as I can't pass a hints with, say, an instance of >>>> NameSpaceSupport as value, because FactoryRegistry will check that for >>>> equality against what FilterFactory.getImplementationHints() returned. >>>> So it seems there's no way of passing a "context" to the filter factory, >>>> neither to the >>>> AttributeExpressions, in order to be able of making them namespace >>>> aware. >>>> >>>> and afaik, at the geotools level we arent applying dependency injection >>>> for this kind of stuff neither... >>>> >>>> suggestions? >>>> >>>> >>>> >>>> Gabriel >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> - This SF.net email is sponsored by DB2 Express >>>> Download DB2 Express C - the FREE version of DB2 express and take >>>> control of your XML. No limits. Just data. Click to get it now. >>>> http://sourceforge.net/powerbar/db2/ >>>> _______________________________________________ >>>> Geotools-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
