On Wed, Jun 13, 2012 at 8:25 AM, <adam.br...@csiro.au> wrote: > Hi Andrea, > > Thank you for your response. I will try to add more explanatory notes to the > proposal when time permits. I considered making several smaller proposals but > decided against it as I didn't think the task lent itself to being broken up; > the individual components wouldn't have any utility on their own... they only > made sense in light of each other. I'll happily stand corrected if others > disagree with that choice, though?
If you are not breaking them up the proposal needs to be expanded to cover also the changes to the wfs store and to their base classes if necessary. It must cover everything you are going to do instead of concentrating on the feature building (that part is good btw). > With regards to your question about how to builder should go about > constructing nested structures and lists: I'm open to suggestions from the > community on this. I'm still in the process of working out what the best > approach is. One approach I've used in the past is to have a method that creates a sub-builder for the nested object, with the parent keeping track of it, when the parent closes up the building it cascades that to all the sub-builders and makes them also build the subfeatures. > I started looking into some validation but ran into problems with cyclic > references in certain types (by that I mean, where two features both refer to > each other); for this reason I must be able to create a technically invalid > feature first, then create the second feature, then link the second feature > to the first. I'm not sure if this is the sort of thing you're referring to? > Either way, I will make any deferred validation optional. Nice. > Now, to answer your questions about the diagrams: > > * Do you think it would be better to have WFSDataAccess implementations that > can handle both Simple and Complex features to avoid having to create two > versions of each? > > * ContentDataAccess: It might be possible to create a ContentDataAccess > hierarchy alongside the ContentDataStore one. I put a note under that diagram > highlighting this possibility, but I didn't know if it would actually be > better to make ContentDataStore and DataStore more generic so they don't > impose a restriction on SimpleFeatures at all? I'm open suggestions... Unfortunately complex features provide extra functionality at a way too high price performance, memory usage and usability wise, so imposing them also on simple feature users is a severe regression. As said earlier, many parts of the code base work only with Simple* classes, if you don't make the store emit simple features for simple cases it will become useless for any but your particular use case. I have several usages of the wfs store that mandate it to be able to produce simple features too, so if the new one doesn't I'll most likely be forced to fork it and create back a simple feature based wfs store (it's certainly going to be much less work than migrate the whole code base out of the Simple* classes usage and also make complex feature suitable for high performance usage). The ideal solution is to have a factory that recognizes the features emitted by a remote WFS server, and returns a DataStore or a DataAccess accordingly. As suggested, one does not need to actually deal with a forked code base, it should be sufficient to: * build SimpleFeatureType and SimpleFeature when the feature is simple * use the DataUtilities.simple(...) methods to force the proper casts * have a new DataUtilities.simple(DataAccess) that can wrap a DataAccess producing only simple features to a DataStore > * The changes I've made to SimpleFeatureBuilder are limited to making it > extend from FeatureBuilder<SimpleFeatureType, SimpleFeature>. There are no > changes to its actual API. Nice Cheers Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------------------------------ 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
