I have applied the patch locally and am reviewing in greater detail; for
reference Niels has provided much more information on the bug report itself:
- http://jira.codehaus.org/browse/GEOT-3374
Going to go with the following for the FilterFactory2 methods
> /**
> * Retrieves the value of a {...@linkplain org.opengis.feature.Feature
> feature}'s property.
> * @param name Name of attribute referenced
> * @return PropertyName
> */
> PropertyName property(Name name);
>
> /**
> * Retrieves the value of a {...@linkplain org.opengis.feature.Feature
> feature}'s property.
> *
> * @param xpath XPath expression (subject to the restrictions of filter
> specificaiton)
> * @param namespaceContext Used to interpret any namespace prefixs in
> above xpath expression
> * @return PropertyName
> */
>
> PropertyName property(String xpath, NamespaceSupport namespaceContext);
Aside; A while ago mbedward wanted to update many of the javadocs for filter,
feature and friends - that is now possible :-)
Jody
On 12/01/2011, at 8:24 PM, Jody Garnett wrote:
> Thanks Niels; reviewing now.
>
> I noticed in PropertyAccessorFactory ...
> public static final Key NAMESPACE_CONTEXT = new
> Hints.Key(org.xml.sax.helpers.NamespaceSupport.class);
> I am a bit worried about funnelling a NamespaceSupport into different
> factories as a Hint; I would like to check where this is used.
>
> Part of why we brought gt-opengis interfaces into the library was so you
> could update the FilterFactory2 - just so a hint was not used (and the
> factory would not be stateful).
> Can we change AttributeExpressionImpl to accept a NamespaceSupport explicitly
> rather than passing it in as part of the hints?
>
> Other than that (because we are defining new api) we need to fill in the
> javadocs (or I will feel guilty making Micheal Bedward work too hard).
>
> Jody
>
>
> On 12/01/2011, at 7:59 PM, Niels wrote:
>
>> I uploaded a patch... If it can be approved before the new release, it would
>> be nice to include it!
>>
>> thx
>> Niels
>>
>> On 12/01/11 13:01, Jody Garnett wrote:
>>>
>>> Have a go at your patch now; I can review when you have it ready.
>>>
>>> Jody
>>>
>>> On 12/01/2011, at 12:12 PM, Niels wrote:
>>>
>>>> Thanks, Jody! That's great.
>>>>
>>>> On 11/01/11 20:27, Jody Garnett wrote:
>>>>>
>>>>> Okay I was able to move CommonFactoryFinder (and a couple of others) over
>>>>> to gt-api.
>>>>>
>>>>> See patch http://jira.codehaus.org/browse/GEOT-3374 for details.
>>>>>
>>>>> Jody
>>>>>
>>>>> On 11/01/2011, at 6:58 PM, Jody Garnett wrote:
>>>>>
>>>>>> Okay tried out your idea Gabriel.
>>>>>>
>>>>>> There are actually two factory finders in play:
>>>>>> - BasicFactories - used by the geometry library implementations; never
>>>>>> hooked up to gt-referencing (and should be used by gt-referencing when
>>>>>> creating direct positions)
>>>>>> - CommonFactoryFinder
>>>>>>
>>>>>> The superclass you mentioned, FactoryFinder, is actually abstract.
>>>>>>
>>>>>> I did try a couple of things:
>>>>>> - moving to gt-metadata; failed as the code references
>>>>>> ReferencingFactoryFinder (probably not that big a deal as we could just
>>>>>> reverse the relationship)
>>>>>> - moving to gt-referencing; failed as CommonFactory finder references
>>>>>> FeatureCollection which is part of gt-api and not an gt-opengis
>>>>>> interface
>>>>>>
>>>>>> I am going to go away and think for a bit.
>>>>>> Jody
>>>>>>
>>>>>> On 11/01/2011, at 3:05 PM, Jody Garnett wrote:
>>>>>>
>>>>>>> A very good idea Gabriel,
>>>>>>>
>>>>>>> I mentioned this on the other email thread but I have an alternative to
>>>>>>> consider?
>>>>>>>
>>>>>>> I would like to collect all the factory finder stuff into the GeoTools
>>>>>>> class; resulting in more readable code. I think we can do this as the
>>>>>>> factory lookup code does not depend on any specific implementation?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jody
>>>>>>>
>>>>>>> On 11/01/2011, at 2:59 PM, Gabriel Roldán wrote:
>>>>>>>
>>>>>>>> On Tue, 2011-01-11 at 13:30 +1000, Jody Garnett wrote:
>>>>>>>>> The namespace 2 discussion has been productive (introducing of
>>>>>>>>> gt-opengis, creation of two proposals) but is now stuck...
>>>>>>>>>
>>>>>>>>> The Query interface would like to work with PropertyName to capture a
>>>>>>>>> list of xpath expressions to be obtained via the Query. To do a nice
>>>>>>>>> job of this it would be good to have access to a FilterFactory (by
>>>>>>>>> way of CommonFactoryFinder).
>>>>>>>>>
>>>>>>>>> Why is this an issue?
>>>>>>>>> - Query is in gt-api
>>>>>>>>> - CommonFactoryFinder is in gt-main
>>>>>>>>>
>>>>>>>>> Any suggestions?
>>>>>>>> not sure it'll work, but FactoryFinder is in gt-metadata, so Query
>>>>>>>> could
>>>>>>>> just use that one provided the lookup method is refactored into
>>>>>>>> FactoryFinder:
>>>>>>>>
>>>>>>>> public class FactoryFinder{
>>>>>>>>
>>>>>>>> public static Object lookup(Class category, Hints hints, Hints.Key key)
>>>>>>>> {
>>>>>>>> hints = mergeSystemHints(hints);
>>>>>>>> ....
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>> Jody
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Gaining the trust of online customers is vital for the success of any
>>>>>>>>> company
>>>>>>>>> that requires sensitive data to be transmitted over the Web. Learn
>>>>>>>>> how to
>>>>>>>>> best implement a security strategy that keeps consumers' information
>>>>>>>>> secure
>>>>>>>>> and instills the confidence they need to proceed with transactions.
>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>>> _______________________________________________
>>>>>>>>> Geotools-devel mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>> --
>>>>>>>> Gabriel Roldan
>>>>>>>> [email protected]
>>>>>>>> Expert service straight from the developers
>>>>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Gaining the trust of online customers is vital for the success of any
>>>>> company
>>>>> that requires sensitive data to be transmitted over the Web. Learn how
>>>>> to
>>>>> best implement a security strategy that keeps consumers' information
>>>>> secure
>>>>> and instills the confidence they need to proceed with transactions.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Geotools-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>>> --
>>>> Niels Charlier
>>>>
>>>> Software Engineer
>>>> CSIRO Earth Science and Resource Engineering
>>>> Phone: +61 8 6436 8914
>>>>
>>>> Australian Resources Research Centre
>>>> 26 Dick Perry Avenue, Kensington WA 6151
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
>>>> Geotools-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>> Niels Charlier
>>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Phone: +61 8 6436 8914
>>
>> Australian Resources Research Centre
>> 26 Dick Perry Avenue, Kensington WA 6151
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
