What is the connection between static XSDHelper calls when definition and load could be using different XSDHelpers for the same instance in the same VM. For example:

XSDHelper.INSTANCE.define(is, null);

and then in another static method xml is loaded

XMLDocument xmlDoc = XMLHelper.INSTANCE.load(is);

Answer: The methods you point out are not static methods, but are executed in the context of the singleton helpers, and the
metadata generated by the XSDHelper.INSTANCE singleton is stored in the TypeHelper.INSTANCE and accessed from there by the
XMLHelper.INSTANCEsingleton. Together these singletons form a default set of helpers centred
around a default scope for types. The recently introduced HelperContext SDO 2.1 API allows you to create new collections of helpers that together define alternative scopes.

Is there support for extending generated SDO implementation classes? Here is my understanding:
1) I cannot have my own superclass of a generated SDO class since this is already occupied
2) I cannot (yet) simply subclass a generated SDO class, this may be addressed in TUSCANY-513
As a consequence I would have to modify the generated SDO implementation class in order to offer custom formatter and validation logic!? Is there eventually a way to inject code using annotations? Or is it possible to re-generate and prevent override of custom code (merge)?*
Answer: The Tuscany SDO generator is currently reusing the code generator
framework from Eclipse EMF project. If you look at the EMF generator, you'll see that it's very powerful and customizable. In Tuscany all we've
done is create a simple command line invocation of the EMF generator, using our own templates, and a few basic options.

One thing we don't support is regen/merge because the EMF merger prereqs the Eclipse JDT, which we didn't want to drag into Tuscany as a
dependency. If someone is willing to write a standalone merger for Tuscany, we could support regen.
Other things like generating a different base class or adding methods, are supported in EMF but we don't have a way do it in with the Tuscany
generator yet. If you'd be willing to help get some of this function into Tuscany, I'm sure a lot of people would be interested in it.

The bottom line is that real sophisticated tooling is outside of the scope of the Tuscany project. Another possible direction for this is for some
Eclipse project to provide a fancy GUI-generator (and possibly other tools) for developing Tuscany SDO applications. It would be nice to see something like that get started.

How do I work with javajet files to modify the SDO generator code
Answer: You can learn how to set up your Eclipse environment to have javajet function built in using this tutorial. Once you have the right eclipse environment you must add a javajet nature to the sdo-tools project, and modify the javajet configuration to match the shape of the sdo-tools project.

  File => New => Other
  Select "Java Emitter Templates"
  Select "Convert Projects to Jet Projects"
  Select "tuscany-sdo-tools"
  Click "Finish"

Then in the Package Explorer pane of the Java perspective of Eclipse, right click on the tuscany-sdo-tools project
  Select "Properties"
  Select "Jet Settings"
  Change the Source Container to "src/main/java"

Following this, when you change the code in templates/models/SDOClass.javajet, or templates/models/SDOFactoryClass.javajet, then the corresponding java class will be updated each time that you save the javajet file.

  • No labels