thanks Martin,
so Jody complained that using a hint to pass namespace context onto FilterFactory would be like mixing construction and logic. some comments inline On Monday 28 May 2007 15:33:10 Martin Desruisseaux wrote: > Gabriel Roldán a écrit : > > 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 ? > > My intend with org.geotools.factory was to handle this kind of case as > below: > > 1) Hints are given to AttributeExpressionImpl constructor. > > 2) AttributeExpressionImpl constructor uses the hints in order to resolve > the factory dependencies right away, and keep the reference to Factory > objects in its private fields. > > 3) AttributeExpressionImpl constructor declares the dependencies resolved > at (2) in its "implementation hints" field, if any. > > I believe that this is the same idea than constructor injection, except > that dependencies are passed as hints rather than explicit constructor > arguments and step 3 doesn't exist for constructor injection. > > > 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. > > Yes, this is the same idea than what I wrote above, except that I would > suggest to resolve the hints right at AttributeExpressionImpl construction > time if possible, both for performance reason and making the system more > predictable. For this particular case, resolving the hints at construction time would be impractical since a given AttributeExpression instance can't know which PropertyAccessor to use until evaluate(Object) is called, as the property accessor to use will depend on the kind of object to evaluate. though it is true that for performance reasons Andrea made the property accessor cached after evaluate was invoked for the first time. > > > 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. > > Unless there is some bug, FactoryRegistry checks for equality against > FilterFactory.getImplementationHints() only in order to see if an existing > instance matches the requested NameSpaceSupport. If no one are found, it > should creates a new factory with the given NameSpaceSupport. but will it cache them? if it does, it'll leak with this approach since every request might potentially use a different NamespaceSupport (i.e. using different prefixes for the same namespaces) > > > and afaik, at the geotools level we arent applying dependency injection > > for this kind of stuff neither... > > Hints are basically constructor injections with dependencies specified in a > HashMap rather than explicit argument constructors. Dependencies in HashMap > provide more flexibility at the expense of less readability, but both > systems could live together. If something can't be done with hints, it is > likely that this particular piece of code is not designed in a way that > looks like constructor injection. indeed, I should've said we're not using an IoC container for this kind of stuff, not that we're not using dependency injection, which was a missconception from my side. Gabriel > > Martin ------------------------------------------------------------------------- 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
