Gabriel Roldán ha scritto: > On Friday 13 March 2009 08:36:35 Jody Garnett wrote: > > Taking this to geoserver-devel; Ben if you have people that would like > > to follow this discussion they can sign up. > > > > > A different collection interface would be preferred, no need to add > > > extra xml specific concerns in all the use cases that do not require > > > it. > > > > > > But quite frankly, this seems unnecessary too. In this JIRA > > > http://jira.codehaus.org/browse/GEOT-2385 > > > you state: > > > "When GeoServer invokes an OutputFormat, it has no access to the WFS > > > feature type name, only the name that can be determined from the > > > FeatureCollection.getSchema(), which is the content model type name" > > > > > > Reality is different, as you have full access to the Operation > > > even in the encoder, meaning this code (which I grabbed from > > > the GML3OutputFormat superclass): > > > > Thanks Andrea that is a much better solution; I would prefer not to > > mess with the FeatureCollection interface; indeed we are trying to > > reduce its scope to something Justin can stand. > > > Indeed Andrea your solution is good as far as getting the feature name > in the encoder stands. I just wanted to point out that going from > FeatureSource to Featurecollection one looses the ability to know > beforehand how those features are to be called, FeatureSource has > getName(), FC doesn't. And wonder how much that impacts more code than > Ben's one once we start getting used to work over the more general > DataAccess/Feature apis. (ie, everytime there's a feature collection > right now it is assumed its features are named the same than the schema, > which is only a good solution -or better a coincidence- for controlled > types like shapefiles and database tables as far as how they're > implemented, but not for app-schemas nor for a WFSDataStore). > > > That said, I'm perhaps being too picky about FC which is not my focus at > all, I'm all for getting it as thin as possible, and I should have > backed my opinion by a more exhaustive evaluation of where in the code > that's going to be a problem. But at least we agree there's a gap in > loosing the ability to get the descriptor name when going from > FeatureSource to FeatureCollection.
I would not say no about the idea of adding getName() to FeatureCollection, as at least we're not breaking existing client code with that change. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
