From: Gabriel R. <gr...@op...> - 2010-12-23 12:51:42
|
+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<nie...@cs...> > > > 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 > > Geo...@li... > > 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<nie...@cs...> > > > 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 > > Geo...@li... > > 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 Geo...@li... https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Gabriel Roldan gr...@op... Expert service straight from the developers |