Hi guys, Sorry to chime in late on this one. Has anything been reached. So I beleive grabriel is right that there is no way to do hints with our expression / api so doing it at the factory level is probably the way to go.
So... instead of getting out of control with containers and injection i think it makes sense to just declare a dependency on whichever namespace support class we use. The parser already seems on org.xml.sax.helpers.NamespaceSupport as Gabriel stated. So i think there should just be a another factory method for propertyName which takes one of these. And then we just patch the implementation of AttributeNameImpl and have it transform as a hint to the PropertyAccessor call. I can see how the depenendency may be unwanted. Especially since its a geoapi interface. So perhaps maybe just add it to the implementation, and the PropertyNameBinding depend on it directly. Does that make any sense? -Justin Gabriel Roldán wrote: > 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 > > !DSPAM:4007,4656c79856871628642973! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
