guys, I'm more than willing to try and provide my view from the past experience with the overrides and all but I guess I'm quite loosing the point of the discussion, sorry.
Ben can you rephrase what the actual problem is with the bindings please? thanks Gabriel Justin Deoliveira wrote: > 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, >> >> > > > ------------------------------------------------------------------------------ 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
