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.
Cheers,
Gabriel.
>
> Jody
>
> ---------------------------------------------------------------------------
>--- 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
--
Gabriel Roldan
http://www.opengeo.org
------------------------------------------------------------------------------
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
