Difference between revisions of "Texo/Texo and EMF"

Revision as of 05:39, 30 January 2010

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 generates pojo's to Texo or EMF classes.

Texo usage of EMF components

Texo uses the following EMF components in its overall solution:

• Runtime model (EClass, EStructuralFeature, etc.)
• 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.

Differences between EMF and 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.
• eContainer or containment associations: although the association definitions are 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 the notification of change is often more useful when committing a database transaction. To for example compare old and new values of efeatures, than when a member is changed in a java object. Also because Texo does not support the EMF bi-directional associations it does not need notifications for this either.
• 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 server side and web UI environments.
• EMF generates an interface and implementation class. Initially Texo will only generate classes (unless the EClass is marked as interface ofcourse) and no separate interface/impl constructs. This has as a consequence that if you want to use multiple inheritance that EClasses have to be explicitly marked as being an interface.

The pojo's generated by Texo do not have any 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

Texo to EMF mapping

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

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. For more information see this [TO ADD FEATUREMAP SUPPORT IN TEXO].