Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Texo/Code Generation Patterns

< Texo
Revision as of 05:32, 14 May 2010 by Mtaal.springsite.com (Talk | contribs) (Introduction)

Introduction

The code generation of Texo can be controlled in detail using annotations. This document describes some possible code generation patterns which can be implemented using annotations. In addition this document describes some other specific code generation patterns implemented by Texo.

Let a non-generated class be used for an EClass

Say that you already have a class which implements an EClass, the java class has getters and setters for the EStructuralFeatures of the EClass. Texo makes it possible to use this custom java class in place of the generated class. So Texo won't generate an entity class but will instead use the custom java class. This means that references to the EClass are generated as references to the custom java class.

For example say you have a model with two EClasses: Car and Owner and there is an EReference Car.owner which references the Owner EClass. Then if the Owner is represented by a custom java class: CustomOwner, Texo will make sure that the getter, setter and java member for Car.owner refers to the CustomOwner class.

To tell Texo to use the custom java class for an EClass, the following has to be done:

  • specify a Model Gen Annotation on the EClass
  • set the 'Generate Code' property to false, this makes sure that Texo won't generate an entity class for this EClass
  • set the 'Qualified Class Name' property to the fully qualified of the custom java class

Handling Feature Maps

EMF uses feature maps for flexible structures present in XML Schema (for example the xsd:choice). For more information on EMF feature maps see the following links:

Texo fully supports the EMF feature map by generating a separate class for a feature map element. The feature map itself then becomes a List which contains the generated feature map entry class.


See this example model, the Library EClass has a feature map people. The people feature is a list of three different types: Writers, Employees, Borrowers. Java can't support a List/Set of different types (other than the very type-unsafe and unexpressive List<Object>). Teneo solves this differently it creates a separate class for the element in the feature map list, in this example a LibraryPeopleFeatureGroup class is generated. This class has several utility methods and methods to set/get a writer, borrower or employees.


Org.eclipse.emf.texo.feature.map.group.png
Org.eclipse.emf.texo.library.fm.methods.png


The advantage of creating a separate class to represent the feature map element is that it fairly straight forward to map this class to a database using an ORM or to other external tools while still maintaining an expressive api.

Generation of a save bi-directional association API (or not)

Only Generate Entities - No EMF dependencies

Generate EMF dependencies in a separate package

Back to the top