Eclipse Community Forums: EMF » Implementing EOperations

Help

Home

Home » Modeling » EMF » Implementing EOperations(What is the ideal implementation for EOperations?)

Show: Today's Messages :: Show Polls :: Message Navigator

Implementing EOperations [message #516101]

Mon, 22 February 2010 18:41

Artur Ribeiro

Messages: 3
Registered: February 2010

Junior Member

So when adding EOperations for generic model operations an empty method body is created. The developer then has several choices on how to fill that empty method. I wonder what would be the most correct. Here is a proposal?

1. Change the JET template for operations gen, interpreting annotation parameters for the EOperation, saying on which class and method the operation can be retrieved. The generated method will delegate the operation to that class:

public Xyx operation(Xyz someArguments) {
   return OperationImplClass.operationImpl(this, someArguments);
}

(OperationImplClass and operationImpl are given by the annotation).

2. Implement the specified external class (Like OperationImplClass).

Is there a simpler way to do it? I am always inclined to avoid any kind of generated code change and this implementation does void that. Although this will generate non-compiling code in case the specified class is not created yet. How was the EOperations concept supposed to be implemented? Wink

Report message to a moderator

Re: Implementing EOperations [message #516107 is a reply to message #516101]

Mon, 22 February 2010 13:58

Christian Damus

Messages: 1270
Registered: July 2009
Location: Canada

Senior Member

Hi, Artur,

If you generate your model using the MDT UML2 extended genmodel, then
you get this delegation-to-static-operations pattern for free. See the
"Operations package" property on the GenPackage in a UML2 generator
model. The genmodel for UML2, itself, is a good example.

Cheers,

Christian

On 22/02/10 01:41 PM, Artur Ribeiro wrote:
> So when adding EOperations for generic model operations an empty method
> body is created. The developer then has several choices on how to fill
> that empty method. I wonder what would be the most correct. Here is a
> proposal?
>
> 1. Change the JET template for operations gen, interpreting annotation
> parameters for the EOperation, saying on which class and method the
> operation can be retrieved. The generated method will delegate the
> operation to that class:
>
> public Xyx operation(Xyz someArguments) {
> return OperationImplClass.operationImpl(this, someArguments);
> }
>
> (OperationImplClass and operationImpl are given by the annotation).
>
> 2. Implement the specified external class (Like OperationImplClass).
>
> Is there a simpler way to do it? I am always inclined to avoid any kind
> of generated code change and this implementation does void that.
> Although this will generate non-compiling code in case the specified
> class is not created yet. How was the EOperations concept supposed to be
> implemented? ;)

Report message to a moderator

Re: Implementing EOperations [message #516109 is a reply to message #516101]

Mon, 22 February 2010 18:54

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------030908050105050003020904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Artur,

Personally I don't have an issue with modifying generated code, given
that the generator supports merging and that Mint shows nicely filtered
views of just my changes, so I generally expect that folks will do
exactly that to implement their operations.

But you can provide your code snippet directly in the model using an
annotation that will be accessed like this in the generator's
GenOperationImpl

protected String getBody()
{
EOperation eOperation = getEcoreOperation();
EAnnotation eAnnotation =
eOperation.getEAnnotation(GenModelPackage.eNS_URI);
return eAnnotation == null ? null :
(String)eAnnotation.getDetails().get("body");
}

Note that you could use

return <%og.example.foo.OperationImplClass%>.operationImpl(this,
someArguments);

so that generating the body will also produce an import.

Artur Ribeiro wrote:
> So when adding EOperations for generic model operations an empty
> method body is created. The developer then has several choices on how
> to fill that empty method. I wonder what would be the most correct.
> Here is a proposal?
>
> 1. Change the JET template for operations gen, interpreting annotation
> parameters for the EOperation, saying on which class and method the
> operation can be retrieved. The generated method will delegate the
> operation to that class:
>
> public Xyx operation(Xyz someArguments) {
> return OperationImplClass.operationImpl(this, someArguments);
> }
>
> (OperationImplClass and operationImpl are given by the annotation).
>
> 2. Implement the specified external class (Like OperationImplClass).
>
> Is there a simpler way to do it? I am always inclined to avoid any
> kind of generated code change and this implementation does void that.
> Although this will generate non-compiling code in case the specified
> class is not created yet. How was the EOperations concept supposed to
> be implemented? ;)

--------------030908050105050003020904
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Artur, 
 
Personally I don't have an issue with modifying generated code, given
that the generator supports merging and that Mint shows nicely filtered
views of just my changes, so I generally expect that folks will do
exactly that to implement their operations. 
 
But you can provide your code snippet directly in the model using an
annotation that will be accessed like this in the generator's
GenOperationImpl 
<blockquote> protected String getBody() 
{ 
 EOperation eOperation = getEcoreOperation(); 
 EAnnotation eAnnotation =
eOperation.getEAnnotation(GenModelPackage.eNS_URI); 
 return eAnnotation == null ? null :
(String)eAnnotation.getDetails().get("body"); 
} 
</blockquote>
Note that you could use 
<blockquote>return
<%og.example.foo.OperationImplClass%>.operatio nImpl(this,
someArguments);
 
</blockquote>
so that generating the body will also produce an import. 
 
 
Artur Ribeiro wrote:
<blockquote cite="mid:hluj40$scf$1@build.eclipse.org" type="cite">So
when adding EOperations for generic model operations an empty method
body is created. The developer then has several choices on how to fill
that empty method. I wonder what would be the most correct. Here is a
proposal?
 
 
1. Change the JET template for operations gen, interpreting annotation
parameters for the EOperation, saying on which class and method the
operation can be retrieved. The generated method will delegate the
operation to that class:
 
 
public Xyx operation(Xyz someArguments) {
 
return OperationImplClass.operationImpl(this, someArguments);
 
}
 
 
(OperationImplClass and operationImpl are given by the annotation).
 
 
2. Implement the specified external class (Like OperationImplClass).
 
 
Is there a simpler way to do it? I am always inclined to avoid any kind
of generated code change and this implementation does void that.
Although this will generate non-compiling code in case the specified
class is not created yet. How was the EOperations concept supposed to
be implemented? ;)
 
</blockquote>
</body>
</html>

--------------030908050105050003020904--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Implementing EOperations [message #516161 is a reply to message #516109]

Mon, 22 February 2010 22:49

Hallvard Traetteberg

Messages: 673
Registered: July 2009
Location: Trondheim, Norway

Senior Member

Ed Merks wrote:
> Artur,
>
> But you can provide your code snippet directly in the model using an
> annotation that will be accessed like this in the generator's
> GenOperationImpl
>
> protected String getBody()
> {
> EOperation eOperation = getEcoreOperation();
> EAnnotation eAnnotation =
> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
> return eAnnotation == null ? null :
> (String)eAnnotation.getDetails().get("body");
> }
>
> Note that you could use
>
> return <%og.example.foo.OperationImplClass%>.operationImpl(this,
> someArguments);
>
> so that generating the body will also produce an import.

I'm surprised you didn't mention that Helios will add support for
delegating to a scripting engine, so your operation may be implemented
in e.g. OCL or Javascript. This works both in generated code and for
dynamic EObjects.

Hallvard

Report message to a moderator

Re: Implementing EOperations [message #516164 is a reply to message #516161]

Mon, 22 February 2010 22:57

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Hallvard,

I considered suggesting that, but my sense was that he's looking to
write the implementation in Java code and just doesn't want to modify
the generated code. I could be wrong. :-)

Hallvard Trætteberg wrote:
> Ed Merks wrote:
>> Artur,
>>
>> But you can provide your code snippet directly in the model using an
>> annotation that will be accessed like this in the generator's
>> GenOperationImpl
>>
>> protected String getBody()
>> {
>> EOperation eOperation = getEcoreOperation();
>> EAnnotation eAnnotation =
>> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
>> return eAnnotation == null ? null :
>> (String)eAnnotation.getDetails().get("body");
>> }
>>
>> Note that you could use
>>
>> return <%og.example.foo.OperationImplClass%>.operationImpl(this,
>> someArguments);
>>
>> so that generating the body will also produce an import.
>
> I'm surprised you didn't mention that Helios will add support for
> delegating to a scripting engine, so your operation may be implemented
> in e.g. OCL or Javascript. This works both in generated code and for
> dynamic EObjects.
>
> Hallvard

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Implementing EOperations [message #516294 is a reply to message #516164]

Tue, 23 February 2010 14:26

Artur Ribeiro

Messages: 3
Registered: February 2010

Junior Member

Yes Ed, that is correct, we were trying to avoid modifying the generated code. And using the annotation to pass the code that will delegate to the real code impl is as good as using an extended genmodel in my honest opinion.

Thank you for your answers.

Ed Merks wrote on Mon, 22 February 2010 17:57

Hallvard,

I considered suggesting that, but my sense was that he's looking to
write the implementation in Java code and just doesn't want to modify
the generated code. I could be wrong. Smile

Hallvard Trætteberg wrote:
> Ed Merks wrote:
>> Artur,
>>
>> But you can provide your code snippet directly in the model using an
>> annotation that will be accessed like this in the generator's
>> GenOperationImpl
>>
>> protected String getBody()
>> {
>> EOperation eOperation = getEcoreOperation();
>> EAnnotation eAnnotation =
>> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
>> return eAnnotation == null ? null :
>> (String)eAnnotation.getDetails().get("body");
>> }
>>
>> Note that you could use
>>
>> return <%og.example.foo.OperationImplClass%>.operationImpl(this,
>> someArguments);
>>
>> so that generating the body will also produce an import.
>
> I'm surprised you didn't mention that Helios will add support for
> delegating to a scripting engine, so your operation may be implemented
> in e.g. OCL or Javascript. This works both in generated code and for
> dynamic EObjects.
>
> Hallvard

Report message to a moderator

Previous Topic:	TreeViewer showing toplevel element
Next Topic:	[Databiding] HowTo configure hibernate (org.hibernate 3.2.6)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 27 02:10:52 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter