|
| Re: Multiple implementations for a single meta-model/interface [message #546583 is a reply to message #546573] |
Tue, 13 July 2010 13:17   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi,
>
> how can we code generate multiple implementations for a single
> meta-model against a single interface (more below)?
>
> By default the code generator creates Java packages for the Java
> interfaces, the Java implementations, and the utility classes
> according to a genmodel.
Yes, and the eINSTANCE references of the factory and package reference a
particular Impl.
>
> We want to use dynamic templates to create multiple implementations
> from the same meta-model (XSD in our case).
>
> We started with a single genmodel file named default.genmodel to
> create the binding with the default templates.
>
> The idea is to create a copy of the default.genmodel and change it so
> it now uses our modified templates and creates the implementation in a
> different "container".
>
> We're not sure what this container might be, a different package a
> different source directory, a different plug-in. In the end we want to
> provide a single set of Java interfaces and still be able to replace
> one implementation with another one without having to change the
> clients using the binding, except perhaps having to change the
> ResourceImpl or other "singular" classes.
There can only be one available at runtime though...
>
> Maybe the picture below helps to understand our demands. It depicts
> what we need for just a single model element.
>
> prefix.X
> / \
> / somewhere(?).Ximpl'
> /
> prefix.impl.XImpl
>
> We're also not sure if this is possible at all.
By hand, but it's not possible to generate this. There is support for a
single factory override where you'd produce other Impls including a
factory and register the factory to override the default/base one.
>
> Any ideas are welcome!
>
> Thanks and regards,
> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Multiple implementations for a single meta-model/interface [message #546601 is a reply to message #546583] |
Tue, 13 July 2010 14:08 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for your hints and see below for what we did and one further
question:
Am 13.07.2010 15:17, schrieb Ed Merks:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Hi,
>>
>> how can we code generate multiple implementations for a single
>> meta-model against a single interface (more below)?
>>
>> By default the code generator creates Java packages for the Java
>> interfaces, the Java implementations, and the utility classes
>> according to a genmodel.
> Yes, and the eINSTANCE references of the factory and package reference a
> particular Impl.
Ok, we have to make sure that the eINSTANCE references are the right ones.
>>
>> We want to use dynamic templates to create multiple implementations
>> from the same meta-model (XSD in our case).
>>
>> We started with a single genmodel file named default.genmodel to
>> create the binding with the default templates.
>>
>> The idea is to create a copy of the default.genmodel and change it so
>> it now uses our modified templates and creates the implementation in a
>> different "container".
>>
>> We're not sure what this container might be, a different package a
>> different source directory, a different plug-in. In the end we want to
>> provide a single set of Java interfaces and still be able to replace
>> one implementation with another one without having to change the
>> clients using the binding, except perhaps having to change the
>> ResourceImpl or other "singular" classes.
> There can only be one available at runtime though...
Yes that will be acceptable.
>>
>> Maybe the picture below helps to understand our demands. It depicts
>> what we need for just a single model element.
>>
>> prefix.X
>> / \
>> / somewhere(?).Ximpl'
>> /
>> prefix.impl.XImpl
>>
>> We're also not sure if this is possible at all.
> By hand, but it's not possible to generate this. There is support for a
> single factory override where you'd produce other Impls including a
> factory and register the factory to override the default/base one.
What we did so far is to generate the alternate implementation into
differently named impl directories by changing the implementation
package suffix in the alternate genmodel file. Despite this we didn't
change the alternate genmodel.
The implementation files get generatded in the directories as specified
in the genmodel file whereas the interface files get generated over
those already generated with the first genmodel.
We did a diff against a copy of the code generated with the first
genmodel. The only relevant differences were in the Package and Factory
interfaces (other differences found only in comments) in the lines
initializing the eINSTANCE references.
So it seems that all we need to do is calling the static init() methods
of the package/factory we want to use and register the result with the
EPackage.Registry.INSTANCE.
Maybe we will split the project into three ones one for the interface
and two for the implementations.
By the way: How can we tweak the code generator so it generates only the
interfaces or only everything but the interfaces?
>>
>> Any ideas are welcome!
>>
>> Thanks and regards,
>> Dirk
|
|
|
| Re: Multiple implementations for a single meta-model/interface [message #546624 is a reply to message #546601] |
Tue, 13 July 2010 14:45 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi Ed,
>
> thanks for your hints and see below for what we did and one further
> question:
>
> Am 13.07.2010 15:17, schrieb Ed Merks:
>> Dirk,
>>
>> Comments below.
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> how can we code generate multiple implementations for a single
>>> meta-model against a single interface (more below)?
>>>
>>> By default the code generator creates Java packages for the Java
>>> interfaces, the Java implementations, and the utility classes
>>> according to a genmodel.
>> Yes, and the eINSTANCE references of the factory and package reference a
>> particular Impl.
> Ok, we have to make sure that the eINSTANCE references are the right
> ones.
>>>
>>> We want to use dynamic templates to create multiple implementations
>>> from the same meta-model (XSD in our case).
>>>
>>> We started with a single genmodel file named default.genmodel to
>>> create the binding with the default templates.
>>>
>>> The idea is to create a copy of the default.genmodel and change it so
>>> it now uses our modified templates and creates the implementation in a
>>> different "container".
>>>
>>> We're not sure what this container might be, a different package a
>>> different source directory, a different plug-in. In the end we want to
>>> provide a single set of Java interfaces and still be able to replace
>>> one implementation with another one without having to change the
>>> clients using the binding, except perhaps having to change the
>>> ResourceImpl or other "singular" classes.
>> There can only be one available at runtime though...
> Yes that will be acceptable.
>>>
>>> Maybe the picture below helps to understand our demands. It depicts
>>> what we need for just a single model element.
>>>
>>> prefix.X
>>> / \
>>> / somewhere(?).Ximpl'
>>> /
>>> prefix.impl.XImpl
>>>
>>> We're also not sure if this is possible at all.
>> By hand, but it's not possible to generate this. There is support for a
>> single factory override where you'd produce other Impls including a
>> factory and register the factory to override the default/base one.
> What we did so far is to generate the alternate implementation into
> differently named impl directories by changing the implementation
> package suffix in the alternate genmodel file. Despite this we didn't
> change the alternate genmodel.
>
> The implementation files get generatded in the directories as
> specified in the genmodel file whereas the interface files get
> generated over those already generated with the first genmodel.
That's a cool trick.
>
> We did a diff against a copy of the code generated with the first
> genmodel. The only relevant differences were in the Package and
> Factory interfaces (other differences found only in comments) in the
> lines initializing the eINSTANCE references.
Yes, that's what I alluded to...
>
> So it seems that all we need to do is calling the static init()
> methods of the package/factory we want to use and register the result
> with the EPackage.Registry.INSTANCE.
Yes, you could put @generated not on those and put in your own logic...
>
> Maybe we will split the project into three ones one for the interface
> and two for the implementations.
There's only a single Model Directory property under which both the
interfaces and implementations are generated...
>
> By the way: How can we tweak the code generator so it generates only
> the interfaces or only everything but the interfaces?
You can add stuff with generator adapters, but it's hard to remove
stuff. I suppose one question to you would be how bad would having
identical duplicates? Your clients could use package imports and resolve
the class in whatever plugin you provide.
>>>
>>> Any ideas are welcome!
>>>
>>> Thanks and regards,
>>> Dirk
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03336 seconds
] 
Search
Help
Register
Login
Home
