Hi Jody, agreed on avoiding mixing construction and logic. I'm not so sure of the utility of a FilterBuilder _just_ to pass the context to FilterFactory, where that could be accomplished by simple constructor injection in the FilterFactory itself (in the geoserver side we're covered by spring), at the complex-datastore lever we would be covered by GTContainer.normal(): DefaultPicoContainer ?
If that sounds good, the only remaining bit is what to use as namespace context in FilterFactory: NamespaceSupport, Map, some new beast? NamespaceSupport seems natural as it is already used in a couple of places, but I don't know if the dependency over org.xml.sax.helpers.NamespaceSupport in FilterFactory will make others happy. Gabriel On Thursday 24 May 2007 18:56:12 Jody Garnett wrote: > 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
