Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
Isn't this already allowed? I didn't think that the runtime actually
forced you to implement your model extensions as interfaces +
implementations... or are we talking about the best practice that we'd
like to promote here?
It works once SDO can use POJOs - before using SDO to load directly
would have required interfaces and codegen (hence the dual model we had).
I'm not sure I understand what you mean by "it works once SDO can use
POJOs".
Before switching to use StAX loaders:
(a) SDOs could already be generated without interfaces using the
-noInterfaces option (the Bigbank sample actually already did that)
(b) The logical model was a POJO model and didn't require interfaces on
extensions AFAIK.
After switching to the StAX loaders and Frank's model proposal:
(a) and (b) are still true
(c) the SDO codegen is getting improved to generate simpler code with no
dependencies on EMF and with some new codegen options no dependencies on
SDO, but that's a different story.
If the question is: Do you want to implement your jsonrpc binding like this?
public interface JSONRPCBinding extends Binding {
}
public class JSONRPCBindingImpl extends BindingImpl implements
JSONRPCBinding {
public JSONRPCBindingImpl() {
}
}
or like this?
public class JSONRPCBindingImpl extends BindingImpl {
public JSONRPCBindingImpl() {
}
}
... then both are possible, before and after the SDO changes.
"Best" practice may be a bit strong - I'm really talking about
"good-enough" practice and balancing flexibility etc. vs. making it easy
for people to add their extensions to the model.
I'm for making it easy for them and would suggest we simplify some of
the existing extensions so that they are easier to understand (e.g. by
converting them to using JavaBeans).
--
Jeremy
Again the current design allows both options, interface+impl or just
impl. Extension developers have a choice, but if they just provide impl
classes they need to realize that they're closing the door to a number
of options:
- alternate implementations of their model in tooling and/or admin
environments, having interfaces allows all the other code to work with
these alternate implementations
- alternate implementations of the same extension model by multiple
providers, for example the container.axis2 and container.celtix projects
may need to implement the WebServiceBinding interface differently at
some point?
- integration with the metadata API, their model may have to be exposed
to application code through the metadata API, and even included in the
SCA spec maybe? I'm not sure that they'll want their implementation
classes to be exposed directly.
So I'm ok with changing one or two sample extension models to just impl
classes if people think it really make a difference. I am not in favor
of changing the "core" ones (Java component type and Web service binding).
--
Jean-Sebastien
