Thanks Gabriel
I only have internet through breaks in the cloud; can we update the change
proposal; and then we need to sort out (with Niels?) a timeframe for
implementation. I am a bit worried that he moved on to the "next" problem; when
I was only trying to help boil email discussion down to a solid proposal.
Jody
On 25/12/2010, at 12:38 AM, Gabriel Roldán wrote:
> +1 on Query.getAttributes():List<PropertyName>
> Sorry I wasn't clear enough.
> On Fri, 2010-12-24 at 16:32 +1100, Jody Garnett wrote:
>> 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<niels.charl...@csiro.au>
>>>>>> 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
>>>>> Geotools-devel@lists.sourceforge.net
>>>>> 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<niels.charl...@csiro.au>
>>>>>> 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
>>>>> Geotools-devel@lists.sourceforge.net
>>>>> 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 Geotools-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>> --
>>> Gabriel Roldan
>>> grol...@opengeo.org
>>> Expert service straight from the developers
>>>
>>
>
> --
> Gabriel Roldan
> grol...@opengeo.org
> 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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
