Home » Modeling » M2T (model-to-text transformation) » Generating code from an ecore-model
|
| Re: Generating code from an ecore-model [message #59701 is a reply to message #59630] |
Wed, 22 April 2009 12:46   |
 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.
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 23:54:26 GMT 2024
Powered by FUDForum. Page generated in 0.02437 seconds |
] 
Search
Help
Register
Login
Home
