+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
------------------------------------------------------------------------------
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
