Gabriel Roldán wrote: > thanks Martin, > > so Jody complained that using a hint to pass namespace context onto > FilterFactory would be like mixing construction and logic. > It won't break me if we are forced to ... it sounds like this information is needed in order to construct correctly? I just want to ask you if you can sort out everything before calling the FilterFactory code? My question is intended as a sanity check, not a veto ...
>> 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. > Interesting .. do we have enough information at "evaluate time" to use the expression? It is an entirely new opportunity to have context ... Andrea's cache can be "reset" if needed ... I think it does so if it encounters a problem working; there may even be a test method ... > 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) > Darn ... good question! >>> 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. > Good discussion guys; looking forward to seeing it resolved. Jody ------------------------------------------------------------------------- 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
