Ben Caradoc-Davies wrote: > Justin Deoliveira wrote: >> Ben Caradoc-Davies wrote: >> Hmmm... I don't see it this way. I mean... every in geoserver there is >> now the decision, if simple feature so this, if complex feature do >> that. I don't see why it cant be the same for GML encoding. If simple >> feature use the regular WFSConfiguration, if complex use the complex >> one. They will share mostly the bindings... except for >> AbstractFeatureTypeBinding, etc... > > How can you serve then both simple and complex from a single GeoServer > instance? I do not think that the dependency injection container is > smart enough to decide which WFSConfiguration to use (it creates the > WFSConfiguration instance). I propose that we (that is, I) fix all the > configurations so they handle complex. There is no performance overhead. > > In my view, there should be no simple features: they are just a profile > of full features and behaviour should be data-driven. I can see that the > "simple features" pattern is very useful for ease of configuration, but > I am pretty sure that there are no significant performance losses in > being generic and treating them the same as other features. Ok I am sort of losing you. I mean, won't the simple case report itself as such by being an instance of DataStore? rather than just a DataAccess?
I don't see it as such an overhead to have a separate configuration... i mean that was what the parser/encoder was designed for: to be flexible enough to plug-in specific bindings for a specific purpose. I *do realize* that your view is that this is not a specific use but a general one. And I respect that that is the view of anyone who is working with application schemas. But you should respect that to most current geoserver users this represents a "new feature" and not a "current defect". So I hope you can see why i am hesitant to make this case the norm. I am not opposed to a unified code path, but i would to know exactly what the complex one looks like first. It seems like a logical and smooth integration path to keep them seperated for now. It is just an if statement and a few extra classes. -Justin > >>> What is the base type of a complexType that extends nothing? >>> XS.COMPLEXTYPE? For example: >>> >>> <complexType name="GeologicFeaturePropertyType"> >>> <sequence minOccurs="0"> >>> <element ref="gsml:GeologicFeature"/> >>> </sequence> >>> <attributeGroup ref="gml:AssociationAttributeGroup"/> >>> </complexType> >> All types extend from xs:anyType. >>> It seems Encoder ignores the content of this at the moment, perhaps >>> because of the ref to an abstract type. Is this an Encoder bug or a >>> missing binding? >>> >> Well... the only binding that would engage in this case would be >> XSAnyTypeBInding. And yeah, it does not implement any of the >> getProperty() methods, so essentially ignored. > > Overriding XSAnyTypeBinding allowed me to encode these types. I have a > few other smallish encoding problems. As soon as I have fixed these, > everything is working. I will contact you then to discuss how we should > integrate these into the code base (pull up into core, or the separate > configuration you propose). I will also set up the CITE tests, as you > requested. > > Kind regards, > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
