I though about this; like the idea of using a List<Name> from an ease of use /
consistency point of view. However I think I may of slightly missed the point
...
In the code example I tried to show the use of an xpath for propertyNames so
you could indicate how much of contained data structures you wanted filled out.
query.setPropertyNames( new
String[]{"foo:x","foo:y","foo:description/foo:label"});
The idea was that a "description" object would be created; but only the "label"
field filled in with a non null result.
This kind of thing we cannot obtain using a List<Name>; but would be possible
with a List<PropertyName>
Jody
On 20/12/2010, at 4:10 PM, Niels wrote:
> On 18/12/10 17:12, Andrea Aime wrote:
>> On Fri, Dec 17, 2010 at 9:03 AM, Niels<[email protected]> wrote:
>>> I think you do need a NameSpace context in your query, because you cannot
>>> assume that the namespace prefixes in the property names of the query are
>>> the same as the ones in the mapping or in the datastore or anywhere else.
>>> The thing about namespace prefixes is that you can never make those
>>> assumptions.
>>> Another solution for Query would be to provide a list of PropertyNames
>>> rather than strings (which is what I suggested earlier I think?) but I guess
>>> that would break too much existing code ?
>> Lucklily Query is not an interface anymore so it _would_ be possible to
>> just add PropertyName (or Name) support and have it fall back on plain
>> strings when the plain string methods are called. The new methods
>> would be used only by code that know about complex features.
>
> I think that is an excellent idea actually... Have two getters and
> settesr for PropertyNames property in Query: one with string[] and one
> with PropertyName[]. The inner representation of the property names in
> the class could be PropertyName[], but when the string[] getter and
> setter are used, conversion is done automatically.
>
> I think that would be even better than having a setNamespaceContext() in
> Query!
>
> Niels
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
On 20/12/2010, at 4:10 PM, Niels wrote:
> On 18/12/10 17:12, Andrea Aime wrote:
>> On Fri, Dec 17, 2010 at 9:03 AM, Niels<[email protected]> wrote:
>>> I think you do need a NameSpace context in your query, because you cannot
>>> assume that the namespace prefixes in the property names of the query are
>>> the same as the ones in the mapping or in the datastore or anywhere else.
>>> The thing about namespace prefixes is that you can never make those
>>> assumptions.
>>> Another solution for Query would be to provide a list of PropertyNames
>>> rather than strings (which is what I suggested earlier I think?) but I guess
>>> that would break too much existing code ?
>> Lucklily Query is not an interface anymore so it _would_ be possible to
>> just add PropertyName (or Name) support and have it fall back on plain
>> strings when the plain string methods are called. The new methods
>> would be used only by code that know about complex features.
>
> I think that is an excellent idea actually... Have two getters and
> settesr for PropertyNames property in Query: one with string[] and one
> with PropertyName[]. The inner representation of the property names in
> the class could be PropertyName[], but when the string[] getter and
> setter are used, conversion is done automatically.
>
> I think that would be even better than having a setNamespaceContext() in
> Query!
>
> Niels
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
