Hi all, have been looking at the proposal, I have to say I'm finding it difficult to read as it crams into a single proposal a number of changes that can be related togheter only under the assumption that one is making a new wfs data store, and as such they do require some familiarity with how the store works (of which I don't have full grasp).
About the "public api to make a wfs request" portion, care should be taken to preserve simple feature usage when possible. E.g., even if the store is a data access it should keep on building simple features and returning SimpleFeatureCollection when the remote type is simple. Which actually seems the direction you're taking when I look at the diagrams, but I'd like to make sure :-) About the new parameters, will they have sane defaults so that one does not need to specify them when hitting a simple feature server? Looking at the complex feature builder the "append" method makes me think about multivalued properties, e.g., something that I could call repeatedly over the same attribute to build the collection of values associated to a property. If it's not meant to be used like that I'd say keep on using "set" would be better, which is already available in the simple feature builder and takes a name (either String or Name). I agree "add" is probably not suitable since it assumes an attribute ordering that in complex features does not appear to be there. Complex features wise we have nested structures and lists, wondering how the builder is going to handle/help with that? Does it make sense to spawn a sub-builder that takes care of assembling a sub-feature or a list of them? I don't see mention of the validating/non validating behavior that SimpleFeatureBuilder has (and which is off by default). We had a long debate over that and concluded validation should be optional, are complex features departing from that? (I actually don't remember exactly why validation was turned off, just remember it was tried out and it did not work in practice). Ah, wondering if the complex feature builder is using converters when setting values like the simple feature builder is. Pretty much all data handling in GeoTools is geared towards trying to "accomodate" first, eventually complain later if adapting is not possible. Looking at the "changed type hierarchies" diagrams: - I see there is a wfs data access factory and a wfs data store factory. How is this going to be played, will we have a complex and a simple wfs data store in parallel? (with the differences in versions one might end up having 6 different store implementation, 1.0, 1.1 and eventually 2.0, simple and complex, ugh...) Also have a look at DataUtilities.simple(...) methods, they can be used to bridge the two worlds in case the contents are simple features (although there is no method to bridge a data store) * DataAccess type hierarchy changed to accommodate WFSContentDataAccess --> does this mean we won't have a ContentDataAccess hierarchy, but just a custom implementation for WFS? * Nice to see the complex and simple feature builders share code.. wondering, will there be any change in the SimpleFeatureBuilder API as a result? Cheers Andrea ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
