Hi Gabriel, You are correct. When using the abstract emf binding classes execution order is irrelevant. The reason being that the binding class handles all properties in the the class hierarchy of the object. So if the execution mode is anything other than override this will probably result in two bindings doing the same work. Does that make sense.
We could modify it so that the binding only handles those properties defined on the interface it is "bound" to. All that really has to change is "getAllEStructuralFeatures()" -> "getEStructuralFeatures()". I kind of like this because its consistent. Want to open a jira for it? Gabriel Roldán wrote: > Hey dude, > > I'm being a bit confused about the bindings semantics. > The thing is it seems with the new relfective settings in > AbstractComplexEMFBinding (which actually is really great), I no longer seem > to be able of completely taking control of a given binding encoding and > parsing. > I.e., for a given binding with has a parent (for example > DescribeFeatureTypeType and BaseRequestTypeType), getExecutionMode() seems t > have no effect over the final result. > I can set DescribeFeatureTypeType execution's mode to either OVERRIDE, BEFORE > or AFTER, and the result of encoding is the same. > If its OVERRIDE, BaseRequestTypeBinding's encode is actually not called, yet > the properties defined in BaseRequestTypeType are written down anyways. > If its BEFORE or AFTER, both bindings encode(..) methods are called in the > correct order depending on the value the execution mode, which is fine. > Yet, in both cases, the object passed to encode(...) is an instance of > DescribeFeatureTypeType. > I seem to remember that in older versions if I set > DescribeFeatureTypeTypeBinding.getExecutionMode() to after, in encode I wold > receive a BaseRequestType instance, instead of DescribeFeatureTypeType? > > That said, things are doing extremely well with the new stuff, I just would > like you to enlighten me on if my understanding of the bindings semantics is > wrong, they changed, or there's something we need to document to make it > clearer? > > regards and hope you're having a lot of fun. > > Gabriel > > > !DSPAM:4007,472eee4611821804284693! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
