I updated the requirements in the wiki page according to our discussions.
From my end: the sooner this can be done, the better! And I volunteer
to help where I am allowed ( in geotools).
On 25/12/10 13:19, Jody Garnett wrote:
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<[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
--
Gabriel Roldan
[email protected]
Expert service straight from the developers
--
*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
------------------------------------------------------------------------------
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
