On Fri, Dec 10, 2010 at 4:49 AM, Niels <[email protected]> wrote: > Currently we are writing the prefix:namespace mappings in the expression's > hints where they are picked up by a property accessor that can handle it. > Because of the dependance it is a very good idea to store it in the > expression object. The issue I am encountering though, is that the existing > API doesn't support property names that contain more information than a > string as a name.
Yep, I told you this one was going to be a can of worms, that's why I suggested to tackle it as the last item in the suggested todo list ;-) > For example, I succeeded in parsing the style file with namespace support, > but then later noticed that the style's filters where being cloned somewhere > by a visitor using a new filter factory and that the hints were being thrown > away. The FilterFactory interface only accepts a string to create a fresh > new PropertyName, and nothing more, and that can't be changed as it is part > of GeoAPI. The only solution I see is to make some interface extensions in > geotools to support xpath property names and some if (instanceof) tricks to > deal with them. Or better to suck back up GeoApi in gt-api and start modifying it there. It's pretty clear we have nothing to share with GeoApi development and if we cannot drive it's just a lead ball to carry around > Another issue is the 'propertynames' field in a Query object. This is > currently implemented as an array of strings. With app-schema, x-paths with > namespaces should be supported for this field, and as I explained before, > there is no guarantee that the prefix mappings in the query are the same as > the ones in the datastore. Currently namespaces just need to be ignored > there, which is a 100% guarantee for buggy behaviour in certain cases. Which means you also need to modify Query and most of its users. Good thing we got rid of the interface, changing a class is easier. One thing I'm worried about is that the GeoServer release is coming and afaik we're basically done with Geotools too, so large API changes should be probably delayed up to the next trunk? Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
