| Extending the given function operators for Acceleo [message #673802] |
Tue, 24 May 2011 19:34  |
 Rainer Menke
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
Hi,
up to now, we use Java Service Wrapper to have a broader functionality in Acceleo ( we have something like create, read and find temoprary properties which can be assigned to EObjects for instance ). Based on the fact, that I assume that additional operations will be required, I would like to ask, how the Acceleo operations could be enhanced with customs operations, so that
a.) It is not required to define invokes
b.) Have a syntax and support like the OCL/Acceleo operators.
Is it possible, to implement this? I tried somethings, but failed up to now. At least I didn't find some information about the library extension point, neither in Acceleo nor in ATL.
Does anybody know how to realize this?
TIA
Rainer Menke
|
|
|
| Re: Extending the given function operators for Acceleo [message #673960 is a reply to message #673802] |
Wed, 25 May 2011 09:50  |
|
Hi,
I cannot speak for ATL (they use their own version of OCL, so adding your own custom operations will probably be harder with them), but at least in Acceleo, we haven't planned any extension point for this. We add our own additional operations to OCL through their environment, and do not allow clients to override said environment for their generation.
We did plan for extension points that would allow you to do it ... but they haven't been tested thoroughly yet. If you wish to try your luck, you need to use the "org.eclipse.acceleo.engine.creator" extension point, which will allow you to contribute your own generation engine to Acceleo. With this, you can simply extend "org.eclipse.acceleo.engine.generation.AcceleoEngine" for this. What you need to override from the default AcceleoEngine is "createEnvironmentFactory" : you need access to the 'EvaluationEnvironment' and 'Environment' in order to call their "addOperations()" methods with those you wish to add. Another option might be to access the "ocl" field of the default AcceleoEngine, and use "ocl.getEnvironment().addHelperOperation()"... which would save you from overriding the environment factory.
If you find that this last option can be used, please raise a bug against Acceleo so that we make this "ocl" field protected instead of private (please try beforehand in order to make sure this last option is sufficient).
Laurent Goubet
Obeo
|
|
|
|
| Re: Extending the given function operators for Acceleo [message #674054 is a reply to message #673960] |
Wed, 25 May 2011 16:57 |
Ed Willink
Messages: 7635
Registered: July 2009 |
Senior Member |
|
|
Hi
The Indigo release of OCL includes a new Xtext-based front-end and
UML-aligned back-end in which the OCL Standard Library is fully modelled
with its own DSL and Xtext editor. The library model is extensible,
importable and replaceable. A library feature comprises two parts; a
declaration in the library model and a link to a Java class that
implements the feature. (Iterations are features so additional iterators
can be added too.).
e.g. some of the current definitions are
type Bag<T> : BagType conformsTo
NonOrderedCollection<T>,NonUniqueCollection<T> {
iteration reject(i : T | body : Lambda T() : Boolean) : Bag<T> =>
'org.eclipse.ocl.examples.library.iterator.RejectIteration';
iteration select(i : T | body : Lambda T() : Boolean) : Bag<T> =>
'org.eclipse.ocl.examples.library.iterator.SelectIteration';
operation "="(object2 : OclAny) : Boolean precedence=EQUALITY =>
'org.eclipse.ocl.examples.library.oclany.OclAnyEqualOperation';
operation "<>"(object2 : OclAny) : Boolean precedence=EQUALITY =>
'org.eclipse.ocl.examples.library.oclany.OclAnyNotEqualOperation';
operation excluding(object : OclAny) : Bag<T> =>
'org.eclipse.ocl.examples.library.collection.CollectionExcludingOperation';
operation flatten<T2>() : Bag<T2> =>
'org.eclipse.ocl.examples.library.collection.CollectionFlattenOperation';
operation including(object : T) : Bag<T> =>
'org.eclipse.ocl.examples.library.collection.CollectionIncludingOperation';
}
/** ... */ comments are also supported so that the next version of the
OCL specification may be auto-generated from this style of model.
See my draft OCL 2011 paper for more details:
http://www.eclipse.org/modeling/mdt/ocl/docs/publications/OCL2011ModelingOCLstdlib/ModelingOCLstdlib.pdf.
Hopefully Acceleo may be able to migrate to exploit this functionality
in Juno. I'm afraid it is of little help to you now.
Regards
Ed Willink
On 25/05/2011 10:50, Laurent Goubet wrote:
> Hi,
>
> I cannot speak for ATL (they use their own version of OCL, so adding
> your own custom operations will probably be harder with them), but at
> least in Acceleo, we haven't planned any extension point for this. We
> add our own additional operations to OCL through their environment,
> and do not allow clients to override said environment for their
> generation.
>
> We did plan for extension points that would allow you to do it ... but
> they haven't been tested thoroughly yet. If you wish to try your luck,
> you need to use the "org.eclipse.acceleo.engine.creator" extension
> point, which will allow you to contribute your own generation engine
> to Acceleo. With this, you can simply extend
> "org.eclipse.acceleo.engine.generation.AcceleoEngine" for this. What
> you need to override from the default AcceleoEngine is
> "createEnvironmentFactory" : you need access to the
> 'EvaluationEnvironment' and 'Environment' in order to call their
> "addOperations()" methods with those you wish to add. Another option
> might be to access the "ocl" field of the default AcceleoEngine, and
> use "ocl.getEnvironment().addHelperOperation()"... which would save
> you from overriding the environment factory.
>
> If you find that this last option can be used, please raise a bug
> against Acceleo so that we make this "ocl" field protected instead of
> private (please try beforehand in order to make sure this last option
> is sufficient).
>
> Laurent Goubet
> Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.02398 seconds
] 
Search
Help
Register
Login
Home
