Jump to: navigation, search

Texo/Texo and EMF

Introduction

Texo is targeted at server-side technology (such as web-server and web-service environments). EMF code generation is more targeted for (or originates from) usage in Eclipse RCP products. This difference in target environment and origin results in differences also in the implementation and delivered functionality.

Still, Texo makes use of EMF and supports similar concepts as EMF where it is appropriate. This is mainly in supporting the model at runtime and for XML serialization. In other areas Texo follows a strict java-only pojo approach and eliminates/prevents any direct compile time references from generated pojo's to Texo or EMF classes.

Why Texo (compared to EMF)

Texo has some overlap with EMF in that it also generates code which represents an ecore model in java. However there are distinctive differences in the approach chosen. These differences are mainly influenced by the target environment and the idea that certain concepts should be implemented completely separate from the generated code.

Texo generates pure pojo's without direct references to EMF or Texo. This makes it easier to integrate with existing frameworks (GWT, ORM solutions).

The behavior of Texo (and its generated code) is exactly what a Java programmer will expect. This in contrast to EMF which sometimes implements XML oriented concepts in the generated code, see for example this discussion thread in the EMF forum on default value handling in EMF.

Some main differences between Texo and EMF:

  • Texo does not generate common EMF patterns such as adapters and notifiers as they make less sense for server-oriented applications.
  • Texo does not use specific/custom collection implementations.
  • Texo uses EMF for XML serialization but the difference is that XML serialization is done completely separate from the generated pojo code. XML serialization is seen as an add-on and as such is not (explicitly) present in the generated code.
  • Texo implements the runtime model outside of the generated pojo entity code. The runtime model is present/initialized in two classes (ModelPackage and ModelFactory) which are (optionally) generated. The pojo classes do not have associations to the runtime model or Texo and neither to EMF.
  • Texo generated pojo's do not (need to) extend BaseEObjectImpl or implement EObject.
  • For code generation Texo uses XPand/Xtend/MWE where EMF uses JET2.

Texo usage of EMF components

Texo uses the following EMF components in its overall solution:

  • Runtime model (EClass, EStructuralFeature, etc.)
  • JMerger to support the same manual change of generated code approach as EMF
  • XSD to Ecore
  • XML serialization

Texo does not make use of the EMF code generation framework. Texo implements its own code generation of entities and pojos using XPand and XTend.

EMF functionality not supported by Texo

The different target environments for EMF and Texo has consequence for the generated code and functionality supported by Texo (compared to EMF). Concretely, Texo does not (and will not) support or generate code with:

  • EMF list implementations such as bidirectional or containment lists. Texo stricly uses standard java collections. Texo supports a safe bi-directional api also, see here.
  • eContainer or containment associations: although the association definitions are used by Texo in the XML serialization they are not explicitly expressed in the java code as now in EMF.
  • Notifications and notifiers: on server side implementations change notifications (and handling) are often more useful when committing a database transaction than when a value in an object changes. * Adapters: the same arguments as for notifications apply here. In server side applications it makes more sense to have transaction-listeners to act upon transaction commit (and then process all changed objects) then when an individual object is changed.
  • Generation of EMF Edit/Editor or other RCP related constructs: Texo is targeted for a different environment: server side and web UI.
  • EMF can generate interfaces and their implementation classes. Initially Texo will only generate classes (unless the EClass is marked as interface ofcourse) and no separate interface/impl files. This has as a consequence that if you want to use multiple inheritance that additional super type EClasses have to be explicitly marked as being an interface.

The pojo's generated by Texo do not have compile time reference to EMF, Texo or other eclipse.org classes.

EMF-functionality to be implemented in Texo

Although some EMF functionality is explicitly not supported there are is also EMF functionality which is currently not supported but which is planned to be supported:

  • The unsettable concept of EMF: is used in XML serialization to determine if an element is present in the XML or not
  • Generic/Parameterized types
  • EOperations
  • DynamicEObject (or in Texo terminology: DynamicModelObject, there is a first implementation available of this concept)

Texo to EMF mapping

Texo has similarities with EMF and some EMF concepts are re-implemented in Texo, in a different way.

Runtime Model

Texo supports the model at runtime (just as EMF does). The generated code does not contain direct references to the runtime model however. Instead Texo generates wrappers which are created at runtime to decorate a pojo with a 'Model-Face'. This is reflected in the Texo Model* classes which form the basis for runtime Model support. The Texo Model* classes can be quite easily mapped to EMF runtime concepts. All the classes can be found in the org.eclipse.emf.texo plugin:

  • ModelPackage: is the equivalent of an EPackage. It takes care of runtime model initialization, provides access to the EPackage, etc. Each EPackage in an ecore model will have an equivalent generated ModelPackage class (the generated class extends ModelPackage).
  • ModelFactory: corresponds to an EFactory. It defines String conversion methods and factory methods for ModelObjects. Each ecore EPackage will have a generated ModelFactory class.
  • ModelObject: the equivalent of the EMF EObject interface. The ModelObject is the interface used by the generated wrappers. For each EClass a wrapper is generated which encapsulates a pojo and gives it a 'Model-face'. The ModelObject provides methods like: eClass, eGet and eSet (see the similarities with EObject).
  • ModelFeatureMapEntry: corresponds to the EMF FeatureMapEntry. This class defines the interface of the generated wrappers for the generated feature map classes. FeatureMaps are used to support flexible XSD construct like the xsd:choice in java.

XML Serialization

Texo makes use of EMF for XML serialization. The main difference with EMF is that concepts needed for XML serialization (eContainer, isSet, etc.) are not generated inside java entity pojos. The XML serialization support is seen as a separate service which does not need to be used at all. The Texo XML serialization support is implemented in the org.eclipse.emf.texo.xml plugin.

For a more detailed description of Texo XML Serialization support see this page.