To which idea is this +1 directed :-)
I am getting a bit nervous watching PropertyName being used as a placeholder
for a generic "qualified" XPath. Still I guess I understand why it is taking
that shape.
So is your +1 for the idea of:
Query.getAttributes(): List<PropertyName> // property name may refer to a
complete xpath
With this in mind getPropertyNames and setPropertyNames would then become a
shortcut methods for the above List.
Jody
On 23/12/2010, at 11:51 PM, Gabriel Roldán wrote:
> +1
>
> On Mon, 2010-12-20 at 17:23 +1100, Jody Garnett wrote:
>> 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
>
> --
> Gabriel Roldan
> [email protected]
> Expert service straight from the developers
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
