+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
