Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » Generating code from an ecore-model
Generating code from an ecore-model [message #59630] Wed, 22 April 2009 08:50 Go to next message
Martin Wolff is currently offline Martin Wolff
Messages: 2
Registered: July 2009
Junior Member
Hello,

My task is to generate source code for another programming language as
java. The input model is a schema file (XSD) respectively an WSDL File.
My current procedure is to use the EMF-Plugin to create an Ecore-Model
from the XSD-File. After that I use a JET Transformation Project with my
own templates and the xyz.ecore file as input to generate code.

My problem right now is, to get the type informations of the model using
XPath expressions.

Example:
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2003/XMLType#//String">

.
</eStructuralTeatures>

This XML-Element has the attribute eType=““. The Type Information
„String“ is coded inside.
If I try to get that attribute with XPath, I get an error that it can't
find that attribute.
Another funny thing is, when I use the dump example that information is
lost in the dump.

Now I have some questions:

How can I get the type information with XPath?

Is it possible (maybe better) to use java in the template to work with the
ecore model?

For example: The EMF plugin use classes like GenClass, GenFeature,
GenModel in there templates to access the ecore-model. Is there a way like
that to access the ecore-model in the JET Transformation Project?

Or is it a better way (is it possible) to use (change) the templates in
the EMF Plugin to work with the ecore-model and to generate non java code?

Thank you very much.
Re: Generating code from an ecore-model [message #59701 is a reply to message #59630] Wed, 22 April 2009 12:46 Go to previous messageGo to next message
Paul Elder is currently offline Paul Elder
Messages: 849
Registered: July 2009
Senior Member
Martin Wolff wrote:

<snip>

> My problem right now is, to get the type informations of the model using
> XPath expressions.

> Example:
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String">
> 
.
> </eStructuralTeatures>

Unless you have explicitly configured JET to treat the input model as XML,
JET is loading the .ecore file using EMF's serialization/deserialization
capabilities. This means that JET is adapting the XPath expressions to
traverse Java objects conforming to these APIs:

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/references/javadoc/org/eclipse/emf/ecore/package-s ummary.html

Looking at the XML on disk can be misleading. What the XPath engine has to
deal with in memory are instances of:

EPackage, EClass, EReference, EAttribute ...

JET maps a XPath steps to methods/attributes on these classes as follows:

* an initial / corresponds the the EMF Resource object.
* a 'contents' step from an EMF Resource object corresponds to calling
Resource.getContents(). Thus /contents returns all the root level objects
stored in an EMF Resource. For a .ecore file, this is typically a single
EPackage object
* for any EObject a 'child' step such as 'eStructuralFeatures' is treated
as follows:
* first an effort is made to find a EReference feature on the EObject's
EClass. I.e., an attempt is made to call getEStructuralFeatures().
* If no such reference is found, the EObjects eContents() method is
called, and each EObject returned has its eClass().getName() compared to
the step name.

For your example, I assume the eStructuralFeatures element represents a
feature of an EClass definition. Lets assume that EClass instance is
refered to by the JET variable eClass:

$eClass/eStructuralFeatures - returns all the EAttribute and EReferences
defined on the EClass itself

$eClass/eAttributes - returns only the EAttributes defined on the EClass
itself

$eClass/eAllAttributes - returns all EAttributes defined directly on the
EClass as well as any EAttributes defined by super classes

You won't see eAttributes or eAllAttributes in the XML - they are
implemented by the ECore API.

Should you really want to filter the results of eStructuralFeatures by
type, you can do something like:

$eClass/eStructuralFeatures[self::EAttribute]


> This XML-Element has the attribute eType=““. The Type Information
> „String“ is coded inside.
> If I try to get that attribute with XPath, I get an error that it can't
> find that attribute.

eType is persisted as an XML attribute, by it is an EReference, so the
correct XPath expression is:

$eAttribute/eType

Note that eType is an instance of EClassifier (see:

http://help.eclipse.org/ganymede/topic/org.eclipse.emf.doc/r eferences/javadoc/org/eclipse/emf/ecore/ETypedElement.html#g etEType()

)

So, you can do things like:

$eAttribute/eType/@name
$eAttribute/eType/@instanceClassName


> Another funny thing is, when I use the dump example that information is
> lost in the dump.

The c:dump tag is incapable of displaying all the information found in
object network such as an ECore model. The best it can do is traverse the
containment features, and show the values of EAttribute features.

It cannot:
* show you non-containment EReferece features
* EReference features that are derived from others (such as eAttributes,
eAllAttributes, ...)

c:dump was intended to be a quick and dirty 'let me see the structure of
my input, and any annotations I've placed on it (via c:set)'. It is
certainly not a reliable and complete serialization of the input model.

Bottom line: when using an EMF-based model as input, don't look at the XML
either in the input document or that produced by c:dump. Look at the Java
API for the model.

> Now I have some questions:

> How can I get the type information with XPath?

In your case, much of the type information you need is revealed in the
API. In general, you can test for a specific EClass using a step such as
self::EAttribute. Note that such a step is essentially equivalent to the
expression currentEObject.eClass().getName().equals("EAttribute"). As a
consequence, this test is equivalent to
'is-an-instance-of-EAttribute-and-not-an-instance-of-any-EAt tribute-subtype'.

It is more difficult to get return the EClass of a particular EObject.
Things like: $eObject/eClass/@name are appealing, but don't work. You
would need to write an XPath function to do it. See this message:

http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg00837.html

> Is it possible (maybe better) to use java in the template to work with the
> ecore model?

It is possible. The initial source object passed to JET is an EMF Resource
object (org.eclipse.emf.ecore.resource.Resource). You could get it with
the following scriptlet:

<%jet imports="org.eclipse.emf.ecore.resource.Resource"%>
<%jet imports="org.eclipse.emf.ecore.*"%>
<%
Resource resource = (Resource)context.getSource();
%>

Personally, I find embedding Java code just obfuscates my templates, but I
have colleagues whom I respect who much prefer Java to XPath and XML tags.

> For example: The EMF plugin use classes like GenClass, GenFeature,
> GenModel in there templates to access the ecore-model. Is there a way like
> that to access the ecore-model in the JET Transformation Project?

The EMF code generator defines an ECore model that defines these GenXXX
classes. Each instance has an EReference to the corresponding EXXX class.
The purpose of the GenXXX classes is to:

1) allow annotations of the ECore classes with information that is
important to code generation. A prime example of this is the GenPackage
class
2) modularize common calculations so that they do not need to be repeated
in templates.

You could use a similar approach with JET. You would have to defined your
own wrapping Gen classes with the appropriate annotations/calculations as
well as references to the original classes. You would then pass an
instance of this 'gen model' to the JET transformation.

JET tries to provide a simpler mechanism if you are looking only at
modularizing common calculations. The c:set tag allows you to 'annotate'
any Object with a new value that then appears to the XPath engine as an
attribute.

<c:set select="...xpath-to-the-object..."
name="...name-the-value...">...the value...</c:set>


> Or is it a better way (is it possible) to use (change) the templates in
> the EMF Plugin to work with the ecore-model and to generate non java code?

We're stepping out of my domain of expertise, but yes and no. The EMF code
generator defines a way for you to provide your own implementation of its
templates. The UML2 API uses precisely these techniques to generate its
API. However, the code generator is fundamentally assuming that you are
writing Java code - I don't think it could persuade it to write C# - it
would still try to put a .java extension on the generated file. But, you
should ask this particular question on the EMF newsgroup. Ed and Dave will
have a much clearer idea. (Incidentally, the EMF code generator does not
use org.eclipse.jet. It uses is own version of JET which is a precursor to
org.eclipse.jet. I sometimes refer to the EMF version as JET1 and
org.eclipse.jet as JET2).

> Thank you very much.
Re: Generating code from an ecore-model [message #59773 is a reply to message #59701] Wed, 22 April 2009 14:44 Go to previous message
Martin Wolff is currently offline Martin Wolff
Messages: 2
Registered: July 2009
Junior Member
> So, you can do things like:
>
> $eAttribute/eType/@name
> $eAttribute/eType/@instanceClassName

This is the answer I have searched for. Now I understand the navigation
through the ecore-model with XPath expressions. With this knowledge, I'll
use the JET Transformation Project to generate code for different
languages.

Thank you very much for your fast answer.
Previous Topic:AMP Proposal, Potential XPAND ui collaborations
Next Topic:Jet2 using Jet2Platform
Goto Forum:
  


Current Time: Mon Sep 22 16:32:49 GMT 2014

Powered by FUDForum. Page generated in 0.01901 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software