Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF Item Providers for interfaces.(The interfaces on the model does not have an Item Provider Generated for them.)
EMF Item Providers for interfaces. [message #1071987] Sun, 21 July 2013 20:15 Go to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Hi!

In our model we supress the generation of interfaces. So only the interface that we model are generated. Playing around with the Edit Framework i have seen that the Item Providers for the modeled interfaces are not created ( or at least not in my case, may be i have overlook something Razz ). I have run into an scenary in which i would like and it would be quite good to have them generated.

The scenario is as follows:

Class A has a lot of Features defined as interfaces.

Different implementations on different plugins or event packages in the same plugin may appear, but we are only intersted on showing a nice common tree view regardless of the different implementations. Having Item Providers Generated for the interfaces will allow us to create a ItemProviderAdapterFactory customize to return only the interfaces Item Providers. This way the TreeView will be independant of what the implmentation of the interfaces are, and no need to add several AdaptorFactorys or search for registerd packets, which seems to me a bit less efficient.

The fist approach to solve the issue ( besides writting the item providers myself but that is agains the whole purpouse of EMF code Generation) was to check the templates, hoping to find a flag that skipped the ItemProviderGeneration if the modeled class was an interface but i could not find it. Then I though of extending the Generator model but I am concern that it will be to no avail, as it seems that the interfaces are ignored completely in the generation of the Edit Framework.


I would appreaciate if somebody could tell me if extending the Generator model is the way to go, and some hints how to get the code generated only for the interfaces (if this could be base in annotations event better Smile)

And just to be sure, is there any particular reason why it should not be generated Item Provider for interfaces?

Cheers,
Javi




Re: EMF Item Providers for interfaces. [message #1072169 is a reply to message #1071987] Mon, 22 July 2013 08:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Xavipen,

Comments below.

On 21/07/2013 10:15 PM, Xavipen Mising name wrote:
> Hi!
>
> In our model we supress the generation of interfaces. So only the
> interface that we model are generated.
I'm not sure I understand exactly what you mean... The second sentence
sounds like a contradiction of the preceding sentence.
> Playing around with the Edit Framework i have seen that the Item
> Providers for the modeled interfaces are not created ( or at least not
> in my case, may be i have overlook something :p ).
Can you provide a specific example of what you mean by a modeled
interface? I assume just an EClass for which you set isInterface and
isAbstract to true but without a instanceTypeName...
> I have run into an scenary in which i would like and it would be quite
> good to have them generated.
>
> The scenario is as follows:
>
> Class A has a lot of Features defined as interfaces.
>
> Different implementations on different plugins or event packages in
> the same plugin may appear, but we are only intersted on showing a
> nice common tree view regardless of the different implementations.
> Having Item Providers Generated for the interfaces will allow us to
> create a ItemProviderAdapterFactory customize to return only the
> interfaces Item Providers. This way the TreeView will be independant
> of what the implmentation of the interfaces are, and no need to add
> several AdaptorFactorys or search for registerd packets, which seems
> to me a bit less efficient.
>
> The fist approach to solve the issue ( besides writting the item
> providers myself but that is agains the whole purpouse of EMF code
> Generation) was to check the templates, hoping to find a flag that
> skipped the ItemProviderGeneration if the modeled class was an
> interface but i could not find it. Then I though of extending the
> Generator model but I am concern that it will be to no avail, as it
> seems that the interfaces are ignored completely in the generation of
> the Edit Framework.
>
>
> I would appreaciate if somebody could tell me if extending the
> Generator model is the way to go, and some hints how to get the code
> generated only for the interfaces (if this could be base in
> annotations event better :))
>
> And just to be sure, is there any particular reason why it should not
> be generated Item Provider for interfaces?
Multiple inheritance would often make it not possible to reuse such things.

Without a small concrete example it's hard to comment on the specific...
>
> Cheers,
> Javi
>
>
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1072224 is a reply to message #1072169] Mon, 22 July 2013 10:37 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Ed Merks wrote on Mon, 22 July 2013 10:15
Xavipen,

Comments below.

On 21/07/2013 10:15 PM, Xavipen Mising name wrote:
> Hi!
>
> In our model we supress the generation of interfaces. So only the
> interface that we model are generated.
I'm not sure I understand exactly what you mean... The second sentence
sounds like a contradiction of the preceding sentence.



I meant that EMF will not automatically generate any Interface for an EClass.

Ed Merks wrote on Mon, 22 July 2013 10:15

> Playing around with the Edit Framework i have seen that the Item
> Providers for the modeled interfaces are not created ( or at least not
> in my case, may be i have overlook something Razz ).
Can you provide a specific example of what you mean by a modeled
interface? I assume just an EClass for which you set isInterface and
isAbstract to true but without a instanceTypeName...


That is correct. I did not know how to expres it.


Ed Merks wrote on Mon, 22 July 2013 10:15

> I have run into an scenary in which i would like and it would be quite
> good to have them generated.
>
> The scenario is as follows:
>
> Class A has a lot of Features defined as interfaces.
>
> Different implementations on different plugins or event packages in
> the same plugin may appear, but we are only intersted on showing a
> nice common tree view regardless of the different implementations.
> Having Item Providers Generated for the interfaces will allow us to
> create a ItemProviderAdapterFactory customize to return only the
> interfaces Item Providers. This way the TreeView will be independant
> of what the implmentation of the interfaces are, and no need to add
> several AdaptorFactorys or search for registerd packets, which seems
> to me a bit less efficient.
>
> The fist approach to solve the issue ( besides writting the item
> providers myself but that is agains the whole purpouse of EMF code
> Generation) was to check the templates, hoping to find a flag that
> skipped the ItemProviderGeneration if the modeled class was an
> interface but i could not find it. Then I though of extending the
> Generator model but I am concern that it will be to no avail, as it
> seems that the interfaces are ignored completely in the generation of
> the Edit Framework.
>
>
> I would appreaciate if somebody could tell me if extending the
> Generator model is the way to go, and some hints how to get the code
> generated only for the interfaces (if this could be base in
> annotations event better Smile)
>
> And just to be sure, is there any particular reason why it should not
> be generated Item Provider for interfaces?

Multiple inheritance would often make it not possible to reuse such things.

Without a small concrete example it's hard to comment on the specific...


I would try to be more specific.

When the Eclass is defined as isInterface false and isAbstract true.
Then in the generated EPackage there are fetures id defined for that EClass.

When the EClass is defined as isInterface true and is Abstract true. (For now on i will refered to this as Einterface for clarity)
Than in the generated EPackage there are no features id defiend for the EClass.

For the EInterfaces I would like to have also Item Provider generated automatically.

I did a bit more digging and i saw that also no features are created for the EInterface in the generated EPackage class.

Regarding Multiple inheritance. I though this is already deal with as an EClass may inherit in the model from several EInterfaces, and the code generation already generates the right features for that EClass. It should not be different for the EInterfaces. Although i admit I may have overlooked something here and that the issue is not as trivial.

As the Einterface is basically and Eclass it should in theory be also possible to generate the feature Ids in the EPackage and an Item Provider.

A particular model example.

Package x
SpaceLayersChain (EClass) contains references:
LayerService1 ( EInterface)
LayerService2 (EInterface) contains references :
Processor (EInterface)


Different models, or packages with in the same model will provide implementations on this LayerServices and Processors.

To offer and unified view of the SpaceLayersChain.

I will create a customize version of the ItemProviderAdapterFactory to only create adapters for the Einterfaces called for this example MyTreeItemProviderAdapterFactory. (The current code will locate and call create for an Einterface but null is return as the switch does not have an itemProvider for the Einterface)

This way it would be possible to create a TreeView as follows:

TreeView tv = new TreeView(tree);
MyTreeItemProviderAdapterFactory adapterFactory = new MyTreeItemProviderAdapterFactory();

AdapterFactoryContentProvider provider = new AdapterFactoryContentProvider(adapterFactory);
AdapterFactoryLabelProvider labelProvider = new AdapterFactoryLabelProvider(adapterFactory);

treeViewer.setContentProvider(provider);
treeViewer.setLabelProvider(labelProvider);

treeViewer.setInput(model);

Simple and clean code independant from all the implementions. Otherwise i have to either create a Composed AdapterFactoy and add an AdpaterFactory per EPackage which contains an implementation or search the registered packages.

I hope i was able to clarify my question a bit more.

Cheers,
Javi

Ed Merks wrote on Mon, 22 July 2013 10:15

>
> Cheers,
> Javi
>
>
>
>
>

Re: EMF Item Providers for interfaces. [message #1072261 is a reply to message #1072224] Mon, 22 July 2013 12:07 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Javi,

Comments below.

On 22/07/2013 12:37 PM, Xavipen Mising name wrote:
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> Xavipen,
>>
>> Comments below.
>>
>> On 21/07/2013 10:15 PM, Xavipen Mising name wrote:
>> > Hi!
>> >
>> > In our model we supress the generation of interfaces. So only the >
>> interface that we model are generated.
>> I'm not sure I understand exactly what you mean... The second
>> sentence sounds like a contradiction of the preceding sentence.
>
>
> I meant that EMF will not automatically generate any Interface for an
> EClass.
So it only generates an implementation class?
>
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> > Playing around with the Edit Framework i have seen that the Item >
>> Providers for the modeled interfaces are not created ( or at least
>> not > in my case, may be i have overlook something :p ). Can you
>> provide a specific example of what you mean by a modeled interface?
>> I assume just an EClass for which you set isInterface and isAbstract
>> to true but without a instanceTypeName...
>
>
> That is correct. I did not know how to expres it.
And somehow you tell EMF not to generate even an interface for this?
I'm confused...
>
>
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> > I have run into an scenary in which i would like and it would be
>> quite > good to have them generated.
>> >
>> > The scenario is as follows:
>> >
>> > Class A has a lot of Features defined as interfaces.
>> >
>> > Different implementations on different plugins or event packages in
>> > the same plugin may appear, but we are only intersted on showing a
>> > nice common tree view regardless of the different implementations.
>> > Having Item Providers Generated for the interfaces will allow us to
>> > create a ItemProviderAdapterFactory customize to return only the >
>> interfaces Item Providers. This way the TreeView will be independant
>> > of what the implmentation of the interfaces are, and no need to add
>> > several AdaptorFactorys or search for registerd packets, which
>> seems > to me a bit less efficient.
>> >
>> > The fist approach to solve the issue ( besides writting the item >
>> providers myself but that is agains the whole purpouse of EMF code >
>> Generation) was to check the templates, hoping to find a flag that >
>> skipped the ItemProviderGeneration if the modeled class was an >
>> interface but i could not find it. Then I though of extending the >
>> Generator model but I am concern that it will be to no avail, as it >
>> seems that the interfaces are ignored completely in the generation of
>> > the Edit Framework.
>> >
>> >
>> > I would appreaciate if somebody could tell me if extending the >
>> Generator model is the way to go, and some hints how to get the code
>> > generated only for the interfaces (if this could be base in >
>> annotations event better :))
>> >
>> > And just to be sure, is there any particular reason why it should
>> not > be generated Item Provider for interfaces?
>>
>> Multiple inheritance would often make it not possible to reuse such
>> things.
>>
>> Without a small concrete example it's hard to comment on the specific...
>
>
> I would try to be more specific.
>
> When the Eclass is defined as isInterface false and isAbstract true.
> Then in the generated EPackage there are fetures id defined for that
> EClass.
Yes, and an interface and implementation class are generated...
>
> When the EClass is defined as isInterface true and is Abstract true.
> (For now on i will refered to this as Einterface for clarity)
> Than in the generated EPackage there are no features id defiend for
> the EClass.
No, that's not true.
>
> For the EInterfaces I would like to have also Item Provider generated
> automatically.
So why not general implementation classes automatically as well. If the
item providers can reuse base item providers for these cases then the
model implementation classes can reuse base implementation classes?
>
> I did a bit more digging and i saw that also no features are created
> for the EInterface in the generated EPackage class.
>
> Regarding Multiple inheritance. I though this is already deal with as
> an EClass may inherit in the model from several EInterfaces, and the
> code generation already generates the right features for that EClass.
> It should not be different for the EInterfaces. Although i admit I may
> have overlooked something here and that the issue is not as trivial.
>
> As the Einterface is basically and Eclass it should in theory be also
> possible to generate the feature Ids in the EPackage and an Item
> Provider.
Feature IDs are generated, so there's something different about what you
have and what you are explaining.
>
> A particular model example.
>
> Package x
> SpaceLayersChain (EClass) contains references:
> LayerService1 ( EInterface)
> LayerService2 (EInterface) contains references :
> Processor (EInterface)
>
>
> Different models, or packages with in the same model will provide
> implementations on this LayerServices and Processors.
>
> To offer and unified view of the SpaceLayersChain.
>
> I will create a customize version of the ItemProviderAdapterFactory to
> only create adapters for the Einterfaces called for this example
> MyTreeItemProviderAdapterFactory. (The current code will locate and
> call create for an Einterface but null is return as the switch does
> not have an itemProvider for the Einterface)
>
> This way it would be possible to create a TreeView as follows:
>
> TreeView tv = new TreeView(tree);
> MyTreeItemProviderAdapterFactory adapterFactory = new
> MyTreeItemProviderAdapterFactory();
>
> AdapterFactoryContentProvider provider = new
> AdapterFactoryContentProvider(adapterFactory);
> AdapterFactoryLabelProvider labelProvider = new
> AdapterFactoryLabelProvider(adapterFactory);
>
> treeViewer.setContentProvider(provider);
> treeViewer.setLabelProvider(labelProvider);
>
> treeViewer.setInput(model);
>
> Simple and clean code independant from all the implementions.
> Otherwise i have to either create a Composed AdapterFactoy and add an
> AdpaterFactory per EPackage which contains an implementation or search
> the registered packages.
>
> I hope i was able to clarify my question a bit more.
>
> Cheers,
> Javi
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> >
>> > Cheers,
>> > Javi
>> >
>> >
>> >
>> >
>> >
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1072279 is a reply to message #1072261] Mon, 22 July 2013 12:51 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Within the Model section of the genModel the following option is configured:

supress interfaces: true.

We do not want to have an interface and an implementation class for each EClass.

In this case an EClass with:

1) isInterface true isAbstract true will generate only an interface.

2) isInterface false isAbstract true will generate only an abstract class.

3) isInterface false is abstract false will generate only a class.

The three cases are an EClass, but only for 2 and 3 are the features Id created in the generated EPackage. I may have something not properly configured, but that is what i see in my generated code.

Also the Item Providers are only generated for cases 2 and 3, I was looking how to get them generated also for case 1.

For what you are saying, at least for the EPackage the features Id for EClass of type 1 should be generated in the following manner.

public static final int GROUND_LAYERS_V1_CHAIN__TC_CODING_LAYER = GROUND_LAYERS_CHAIN__TC_CODING_LAYER;

However, they are not in my case...

I can try to put an example ecore model and genmodel, if it helps.

Ed Merks wrote on Mon, 22 July 2013 14:07
Javi,

Comments below.

On 22/07/2013 12:37 PM, Xavipen Mising name wrote:
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> Xavipen,
>>
>> Comments below.
>>
>> On 21/07/2013 10:15 PM, Xavipen Mising name wrote:
>> > Hi!
>> >
>> > In our model we supress the generation of interfaces. So only the >
>> interface that we model are generated.
>> I'm not sure I understand exactly what you mean... The second
>> sentence sounds like a contradiction of the preceding sentence.
>
>
> I meant that EMF will not automatically generate any Interface for an
> EClass.In the genmodel the following is configured.
So it only generates an implementation class?
>
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> > Playing around with the Edit Framework i have seen that the Item >
>> Providers for the modeled interfaces are not created ( or at least
>> not > in my case, may be i have overlook something Razz ). Can you
>> provide a specific example of what you mean by a modeled interface?
>> I assume just an EClass for which you set isInterface and isAbstract
>> to true but without a instanceTypeName...
>
>
> That is correct. I did not know how to expres it.
And somehow you tell EMF not to generate even an interface for this?
I'm confused...
>
>
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> > I have run into an scenary in which i would like and it would be
>> quite > good to have them generated.
>> >
>> > The scenario is as follows:
>> >
>> > Class A has a lot of Features defined as interfaces.
>> >
>> > Different implementations on different plugins or event packages in
>> > the same plugin may appear, but we are only intersted on showing a
>> > nice common tree view regardless of the different implementations.
>> > Having Item Providers Generated for the interfaces will allow us to
>> > create a ItemProviderAdapterFactory customize to return only the >
>> interfaces Item Providers. This way the TreeView will be independant
>> > of what the implmentation of the interfaces are, and no need to add
>> > several AdaptorFactorys or search for registerd packets, which
>> seems > to me a bit less efficient.
>> >
>> > The fist approach to solve the issue ( besides writting the item >
>> providers myself but that is agains the whole purpouse of EMF code >
>> Generation) was to check the templates, hoping to find a flag that >
>> skipped the ItemProviderGeneration if the modeled class was an >
>> interface but i could not find it. Then I though of extending the >
>> Generator model but I am concern that it will be to no avail, as it >
>> seems that the interfaces are ignored completely in the generation of
>> > the Edit Framework.
>> >
>> >
>> > I would appreaciate if somebody could tell me if extending the >
>> Generator model is the way to go, and some hints how to get the code
>> > generated only for the interfaces (if this could be base in >
>> annotations event better Smile)
>> >
>> > And just to be sure, is there any particular reason why it should
>> not > be generated Item Provider for interfaces?
>>
>> Multiple inheritance would often make it not possible to reuse such
>> things.
>>
>> Without a small concrete example it's hard to comment on the specific...
>
>
> I would try to be more specific.
>
> When the Eclass is defined as isInterface false and isAbstract true.
> Then in the generated EPackage there are fetures id defined for that
> EClass.
Yes, and an interface and implementation class are generated...
>
> When the EClass is defined as isInterface true and is Abstract true.
> (For now on i will refered to this as Einterface for clarity)
> Than in the generated EPackage there are no features id defiend for
> the EClass.
No, that's not true.
>
> For the EInterfaces I would like to have also Item Provider generated
> automatically.
So why not general implementation classes automatically as well. If the
item providers can reuse base item providers for these cases then the
model implementation classes can reuse base implementation classes?


Because not all interfaces will be implemented as some of then are just to define services and one implemention may be a composition of some of these services or a service specialization.

Quote:

>
> I did a bit more digging and i saw that also no features are created
> for the EInterface in the generated EPackage class.
>
> Regarding Multiple inheritance. I though this is already deal with as
> an EClass may inherit in the model from several EInterfaces, and the
> code generation already generates the right features for that EClass.
> It should not be different for the EInterfaces. Although i admit I may
> have overlooked something here and that the issue is not as trivial.
>
> As the Einterface is basically and Eclass it should in theory be also
> possible to generate the feature Ids in the EPackage and an Item
> Provider.
Feature IDs are generated, so there's something different about what you
have and what you are explaining.
>
> A particular model example.
>
> Package x
> SpaceLayersChain (EClass) contains references:
> LayerService1 ( EInterface)
> LayerService2 (EInterface) contains references :
> Processor (EInterface)
>
>
> Different models, or packages with in the same model will provide
> implementations on this LayerServices and Processors.
>
> To offer and unified view of the SpaceLayersChain.
>
> I will create a customize version of the ItemProviderAdapterFactory to
> only create adapters for the Einterfaces called for this example
> MyTreeItemProviderAdapterFactory. (The current code will locate and
> call create for an Einterface but null is return as the switch does
> not have an itemProvider for the Einterface)
>
> This way it would be possible to create a TreeView as follows:
>
> TreeView tv = new TreeView(tree);
> MyTreeItemProviderAdapterFactory adapterFactory = new
> MyTreeItemProviderAdapterFactory();
>
> AdapterFactoryContentProvider provider = new
> AdapterFactoryContentProvider(adapterFactory);
> AdapterFactoryLabelProvider labelProvider = new
> AdapterFactoryLabelProvider(adapterFactory);
>
> treeViewer.setContentProvider(provider);
> treeViewer.setLabelProvider(labelProvider);
>
> treeViewer.setInput(model);
>
> Simple and clean code independant from all the implementions.
> Otherwise i have to either create a Composed AdapterFactoy and add an
> AdpaterFactory per EPackage which contains an implementation or search
> the registered packages.
>
> I hope i was able to clarify my question a bit more.
>
> Cheers,
> Javi
> Ed Merks wrote on Mon, 22 July 2013 10:15
>> >
>> > Cheers,
>> > Javi
>> >
>> >
>> >
>> >
>> >
>
>

Re: EMF Item Providers for interfaces. [message #1072290 is a reply to message #1072279] Mon, 22 July 2013 13:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Javi,

Comments below.

On 22/07/2013 2:51 PM, Xavipen Mising name wrote:
> Within the Model section of the genModel the following option is
> configured:
>
> supress interfaces: true.
>
> We do not want to have an interface and an implementation class for
> each EClass.
Hmmm. What's your purpose in doing that? It's one of those ugly options
that was added to deal with people at my company who said "JAXB can do
that and we like that way more" and then sadly they never used EMF
anyway because they were just making up excuses on the fly...
>
> In this case an EClass with:
>
> 1) isInterface true isAbstract true will generate only an interface.
Yes, isInterface true implies that no implementation class will be
generated.
>
> 2) isInterface false isAbstract true will generate only an abstract
> class.
>
> 3) isInterface false is abstract false will generate only a class.
>
> The three cases are an EClass, but only for 2 and 3 are the features
> Id created in the generated EPackage.
Not when I try it. There should always be feature constants for classes
with features.
> I may have something not properly configured, but that is what i see
> in my generated code.
An example that reproduces your scenario would be useful.
> Also the Item Providers are only generated for cases 2 and 3, I was
> looking how to get them generated also for case 1.
Yes, must like the case of whether an implementation class is
generated. If there is reusable code for the item providers I imagine
there should be reusable code for the implementation classes too...
>
> For what you are saying, at least for the EPackage the features Id for
> EClass of type 1 should be generated in the following manner.
> public static final int GROUND_LAYERS_V1_CHAIN__TC_CODING_LAYER =
> GROUND_LAYERS_CHAIN__TC_CODING_LAYER;
Ah, now I see what you're saying. But those are used only in an
implementation class which isn't generated and when there is no
generated implementation class there's no generated item provider
either... But your claim is that while the item providers would contain
reusable code, the model classes don't and you'd rather have those
implementation details duplicated in derived classes. It's hard to
imagine how that's the case.
>
> However, they are not in my case...
>
> I can try to put an example ecore model and genmodel, if it helps.
>
> Ed Merks wrote on Mon, 22 July 2013 14:07
>> Javi,
>>
>> Comments below.
>>
>> On 22/07/2013 12:37 PM, Xavipen Mising name wrote:
>> > Ed Merks wrote on Mon, 22 July 2013 10:15
>> >> Xavipen,
>> >>
>> >> Comments below.
>> >>
>> >> On 21/07/2013 10:15 PM, Xavipen Mising name wrote:
>> >> > Hi!
>> >> >
>> >> > In our model we supress the generation of interfaces. So only
>> the > >> interface that we model are generated.
>> >> I'm not sure I understand exactly what you mean... The second >>
>> sentence sounds like a contradiction of the preceding sentence.
>> >
>> >
>> > I meant that EMF will not automatically generate any Interface for
>> an > EClass.In the genmodel the following is configured.
>> So it only generates an implementation class?
>> >
>> > Ed Merks wrote on Mon, 22 July 2013 10:15
>> >> > Playing around with the Edit Framework i have seen that the Item
>> > >> Providers for the modeled interfaces are not created ( or at
>> least >> not > in my case, may be i have overlook something :p ). Can
>> you >> provide a specific example of what you mean by a modeled
>> interface? >> I assume just an EClass for which you set isInterface
>> and isAbstract >> to true but without a instanceTypeName...
>> >
>> >
>> > That is correct. I did not know how to expres it.
>> And somehow you tell EMF not to generate even an interface for this?
>> I'm confused...
>> >
>> >
>> > Ed Merks wrote on Mon, 22 July 2013 10:15
>> >> > I have run into an scenary in which i would like and it would be
>> >> quite > good to have them generated.
>> >> >
>> >> > The scenario is as follows:
>> >> >
>> >> > Class A has a lot of Features defined as interfaces.
>> >> >
>> >> > Different implementations on different plugins or event packages
>> in >> > the same plugin may appear, but we are only intersted on
>> showing a >> > nice common tree view regardless of the different
>> implementations. >> > Having Item Providers Generated for the
>> interfaces will allow us to >> > create a ItemProviderAdapterFactory
>> customize to return only the > >> interfaces Item Providers. This way
>> the TreeView will be independant >> > of what the implmentation of
>> the interfaces are, and no need to add >> > several AdaptorFactorys
>> or search for registerd packets, which >> seems > to me a bit less
>> efficient.
>> >> >
>> >> > The fist approach to solve the issue ( besides writting the item
>> > >> providers myself but that is agains the whole purpouse of EMF
>> code > >> Generation) was to check the templates, hoping to find a
>> flag that > >> skipped the ItemProviderGeneration if the modeled
>> class was an > >> interface but i could not find it. Then I though of
>> extending the > >> Generator model but I am concern that it will be
>> to no avail, as it > >> seems that the interfaces are ignored
>> completely in the generation of >> > the Edit Framework.
>> >> >
>> >> >
>> >> > I would appreaciate if somebody could tell me if extending the >
>> >> Generator model is the way to go, and some hints how to get the
>> code >> > generated only for the interfaces (if this could be base in
>> > >> annotations event better :))
>> >> >
>> >> > And just to be sure, is there any particular reason why it
>> should >> not > be generated Item Provider for interfaces?
>> >>
>> >> Multiple inheritance would often make it not possible to reuse
>> such >> things.
>> >>
>> >> Without a small concrete example it's hard to comment on the
>> specific...
>> >
>> >
>> > I would try to be more specific.
>> >
>> > When the Eclass is defined as isInterface false and isAbstract
>> true. > Then in the generated EPackage there are fetures id defined
>> for that > EClass.
>> Yes, and an interface and implementation class are generated...
>> >
>> > When the EClass is defined as isInterface true and is Abstract
>> true. > (For now on i will refered to this as Einterface for clarity)
>> > Than in the generated EPackage there are no features id defiend for
>> > the EClass.
>> No, that's not true.
>> >
>> > For the EInterfaces I would like to have also Item Provider
>> generated > automatically.
>> So why not general implementation classes automatically as well. If
>> the item providers can reuse base item providers for these cases then
>> the model implementation classes can reuse base implementation classes?
>
>
> Because not all interfaces will be implemented as some of then are
> just to define services and one implemention may be a composition of
> some of these services or a service specialization.
>
> Quote:
>> >
>> > I did a bit more digging and i saw that also no features are
>> created > for the EInterface in the generated EPackage class.
>> >
>> > Regarding Multiple inheritance. I though this is already deal with
>> as > an EClass may inherit in the model from several EInterfaces, and
>> the > code generation already generates the right features for that
>> EClass. > It should not be different for the EInterfaces. Although i
>> admit I may > have overlooked something here and that the issue is
>> not as trivial.
>> >
>> > As the Einterface is basically and Eclass it should in theory be
>> also > possible to generate the feature Ids in the EPackage and an
>> Item > Provider.
>> Feature IDs are generated, so there's something different about what
>> you have and what you are explaining.
>> >
>> > A particular model example.
>> >
>> > Package x
>> > SpaceLayersChain (EClass) contains references:
>> > LayerService1 ( EInterface)
>> > LayerService2 (EInterface) contains references :
>> > Processor (EInterface)
>> >
>> >
>> > Different models, or packages with in the same model will provide >
>> implementations on this LayerServices and Processors.
>> >
>> > To offer and unified view of the SpaceLayersChain.
>> >
>> > I will create a customize version of the ItemProviderAdapterFactory
>> to > only create adapters for the Einterfaces called for this example
>> > MyTreeItemProviderAdapterFactory. (The current code will locate and
>> > call create for an Einterface but null is return as the switch does
>> > not have an itemProvider for the Einterface)
>> >
>> > This way it would be possible to create a TreeView as follows:
>> >
>> > TreeView tv = new TreeView(tree);
>> > MyTreeItemProviderAdapterFactory adapterFactory = new >
>> MyTreeItemProviderAdapterFactory();
>> >
>> > AdapterFactoryContentProvider provider = new >
>> AdapterFactoryContentProvider(adapterFactory);
>> > AdapterFactoryLabelProvider labelProvider = new >
>> AdapterFactoryLabelProvider(adapterFactory);
>> >
>> > treeViewer.setContentProvider(provider);
>> > treeViewer.setLabelProvider(labelProvider);
>> >
>> > treeViewer.setInput(model);
>> >
>> > Simple and clean code independant from all the implementions. >
>> Otherwise i have to either create a Composed AdapterFactoy and add an
>> > AdpaterFactory per EPackage which contains an implementation or
>> search > the registered packages.
>> >
>> > I hope i was able to clarify my question a bit more.
>> >
>> > Cheers,
>> > Javi
>> > Ed Merks wrote on Mon, 22 July 2013 10:15
>> >> >
>> >> > Cheers,
>> >> > Javi
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >
>> >
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1072348 is a reply to message #1072290] Mon, 22 July 2013 15:17 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Hi Ed,

First, after rechecking, i was wrong in one claim. The feature constants for classes with features are actually generated. I was looking the wrong genereted EPackage.

However the Item Providers are not Generated.

I have put together an example ecore model with a genmodel, to show why we use supress interfaces: true.

The main reason is that we do not want interfaces generated automatically for all the EClass. Like MulitplexorFifo, MultiplexorPriority etc.. in the example attached.

There may be other way to achieve this but i did not see it.

In the model the package named other, could actually be in another plugin with uses the example ecore model to provide additional implementations, but i put everything in one ecore model to keep it simple.

If Item Providers would be generated for MultiplerxorV1 and Filter, they could be use to create an Adapter Factory for those item providers to use it with a Viewers and not have to worry about the implementation adapter factory with for the case would be irrelevant. Unfortunately this item providers are not generated.


Cheers,
Javi

  • Attachment: My.ecore
    (Size: 1.78KB, Downloaded 213 times)
  • Attachment: My.genmodel
    (Size: 2.06KB, Downloaded 265 times)
Re: EMF Item Providers for interfaces. [message #1123430 is a reply to message #1072348] Wed, 02 October 2013 14:58 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Any ideas on how to generated ItemProviders for classes modelled as Interfaces(Properties abstract and interface set to true in the model) I have post an example where this would be useful.

I do not mind to do the changes myself, just looking for a point where to add this capability. I have reviewed the templates for code generation but i could not find anything there.

Any help or suggestion would be appreciated
Cheers,
Javi
Re: EMF Item Providers for interfaces. [message #1123483 is a reply to message #1123430] Wed, 02 October 2013 16:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Xavipen,

Comments below.

On 02/10/2013 4:58 PM, Xavipen Mising name wrote:
> Any ideas on how to generated ItemProviders for classes modelled as
> Interfaces(Properties abstract and interface set to true in the model)
> I have post an example where this would be useful.
> I do not mind to do the changes myself, just looking for a point where
> to add this capability. I have reviewed the templates for code
> generation but i could not find anything there.
Again, you don't want a generated implementation class because you don't
believe there's reusable code there, but you do want a generated item
provider for exactly that same thing because there you believe there
will be reusable code. It's hard to imagine that's the case. And your
issue about wanting to use exactly those adapters that aren't currently
generated anyway doesn't make a lot of sense either. At some point
there must be some concrete class that really does implement that
interface and you'll use the generated item provider for that. Your
base editor doesn't need to worry about such details because the item
providers for such derived classes will be registered and automatically
available. So I get the sense you're trying to solve something that's
not a really problem and in the end there is no direct solution without
changing how EMF's generator works.
>
> Any help or suggestion would be appreciated
> Cheers,
> Javi


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1125709 is a reply to message #1123483] Fri, 04 October 2013 20:16 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
After some digging on the codegen generator i found the following in the GenClassImpl

@Override
public boolean canGenerateEdit()
{
return super.canGenerateEdit() && !isInterface() && getProvider() != GenProviderKind.NONE_LITERAL;
}

The !isInterface() is the reason why no ItemProviders will ever be generated for Eclass with property interfaces set to true. Having ItemProviders generated for these "EClass interfaces" has great advantages as i have explain befored in the post. Is there any reason/issue why they are not being generated?

Re: EMF Item Providers for interfaces. [message #1125732 is a reply to message #1123483] Fri, 04 October 2013 20:47 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Sorry Ed, I did not see your reply.

First, I will try to clarificate why for my case is useful to have Supress Interface to true ( I will get to the Item Providers in a minute).

There is a bundle/with a model for a service called Multiplexor. It has methods and a couple of attributes.

However there are more than one implementation for the multiplexor service. In the same bundle you would have MultiplexorFIFO and MultiplexorList (just made up names)

In another bundle you may extend the model to provide another implementation of the service. Let´s say MultiplexorPriority

I would like to only have one interface ( defining the service) and three different implementation class with do not need to defined additional interfaces. These is my reason for selecting Supress interfaces to true. If I would select Supress interface false I would have 4 EClass modelled but i would end up with 4 interfaces generated (where i only really need one) and implementation classes.


Now going to the point of why i see useful the ItemProviders for interfaces (this is beside the discussion on whether to have supress interfaces to true or not).

If i would like an extensible application where several different implementations should coexist and you do not know before hand which this implementations may be, but you want to be able to have a let´s say tree view (The example above still valid for this). You could do two things:

1) Set an ComposedAdapterFactory with all the registered adapter factories.

This would work but if you have modelled a lot of packages there will be a lot of search in adapterFactories that are not needed and you may not get an unified view for the multiplexor service, which sometimes is what is needed.

2) If ItemProviders would be generated for the interface you could use only the ItemAdaptorFactory genereated for the package where your interface is. (Multiplexor in this case.) Then you will have a common display for all implementation of the services and no need to see for regiestered AdapterFactories additional bundles that offer other implementations. The plus it that you offer a commen itemProvider for all the implementation through the "interfaceItemProvider".

You still would like specialice views base on the implementations using the implementation providers and there adapter factories. The difference is that now it is a choice which way you show it in your view.

Having the ItemProviders generated for the interfaces has no disadvantage and some advantages. Unless of course there are other issues that i am not aware of. Changing the generator to allow this is just removing a couple of characters in a method. Moreover, if you do not one the ItemProviders to be generated in the genmodel can be set the ItemProvider to NONE.

I hope i have explain be better this time.
Best Regards,
Javi

Re: EMF Item Providers for interfaces. [message #1126145 is a reply to message #1125732] Sat, 05 October 2013 07:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Xavipen,

Comments below.

On 04/10/2013 10:47 PM, Xavipen Mising name wrote:
> Sorry Ed, I did not see your reply.
> First, I will try to clarificate why for my case is useful to have
> Supress Interface to true ( I will get to the Item Providers in a
> minute).
>
> There is a bundle/with a model for a service called Multiplexor. It
> has methods and a couple of attributes.
> However there are more than one implementation for the multiplexor
> service.
Which will all have the same attributes though perhaps different
implementations of the operations.
> In the same bundle you would have MultiplexorFIFO and MultiplexorList
> (just made up names)
Or they could be in other models, it doesn't much matter...
>
> In another bundle you may extend the model to provide another
> implementation of the service. Let´s say MultiplexorPriority
> I would like to only have one interface ( defining the service) and
> three different implementation class with do not need to defined
> additional interfaces.
Though there will be additional factory methods for creating these
additional things.
> These is my reason for selecting Supress interfaces to true. If I
> would select Supress interface false I would have 4 EClass modelled
You do have four EClasses modeled.
> but i would end up with 4 interfaces generated (where i only really
> need one) and implementation classes.
How is Suppress Interfaces related to marking EClass.isInterface
true? You use the latter to force an interface to be generated and
you use the former to eliminate the otherwise empty interfaces?

From your description it sounds like the base EClass has attributes and
that you're duplicating the implementation of those attributes three
times. You could accomplish the same thing as followings (using Xcore
notation)

package org.example

class Base
{
String attribute
op void foo()
}

class Derived1 extends Base wraps Base
{
op void foo()
{
// Do something.
}
}

class Derived2 extends Base wraps Base
{
op void foo()
{
// Do something else.
}
}

I.e., by setting the instanceTypeName of the derived EClasses to the
generated interface of the base EClass, you'll effectively suppress the
generation of an interface for them. But you'll still generate an
implementation class that can still share the common code in the Base
class implementation.
>
>
> Now going to the point of why i see useful the ItemProviders for
> interfaces (this is beside the discussion on whether to have supress
> interfaces to true or not).
> If i would like an extensible application where several different
> implementations should coexist and you do not know before hand which
> this implementations may be, but you want to be able to have a let´s
> say tree view (The example above still valid for this). You could do
> two things:
>
> 1) Set an ComposedAdapterFactory with all the registered adapter
> factories.
>
> This would work but if you have modelled a lot of packages there will
> be a lot of search in adapterFactories that are not needed and you may
> not get an unified view for the multiplexor service, which sometimes
> is what is needed.
No, this statement sounds bogus. There is no significant performance
overhead, and you've overlooked several things. Derived classes may
introduce additional features that one would expect to appear in the
properties view. Also, derived classes should likely display a
different icon so the unified view's user can distinguish the different
behaviors implied by the different implementation classes.
>
> 2) If ItemProviders would be generated for the interface you could use
> only the ItemAdaptorFactory genereated for the package where your
> interface is. (Multiplexor in this case.) Then you will have a common
> display for all implementation of the services and no need to see for
> regiestered AdapterFactories additional bundles that offer other
> implementations. The plus it that you offer a commen itemProvider for
> all the implementation through the "interfaceItemProvider".
If you define your model as above, you won't have this problem, and
you'll have a single implementation of the attributes as well.
>
> You still would like specialice views base on the implementations
> using the implementation providers and there adapter factories. The
> difference is that now it is a choice which way you show it in your view.
>
> Having the ItemProviders generated for the interfaces has no
> disadvantage and some advantages.
I believe whenever that statement is true, it's also true of the
generated implementation class, and even in the example you outline,
that's the case, i.e., you have attributes and all the associated
reflective scaffolding that's being duplicate because you don't have a
common implementation class. A typical reason for marking something as
an interface is because one expects that interface to be used in
multiple inheritance where it's not the primary inheritance and hence
the implementation class will not be reused by the derived classes; when
that's the case for the model classes, that's also the case for the item
providers, which use the same approach. So simply generating all item
providers might well result in item providers that simply are never used
directly and are simply never the base class for some other item
provider that is actually used.
> Unless of course there are other issues that i am not aware of.
> Changing the generator to allow this is just removing a couple of
> characters in a method.
Those characters didn't get there accidentally, they were put there
deliberately.
> Moreover, if you do not one the ItemProviders to be generated in the
> genmodel can be set the ItemProvider to NONE.
> I hope i have explain be better this time.
Yes, but there are several flaws in the arguments and with the approach
you've taken. E.g., the generated factory's create methods for these
derived classes returns what type of thing? With the approach I
outlined above, you end up with something cleaner where you don't end up
with implementation classes visible in your API, you do have a common
base implementation class to avoid duplicate code across derived classes
that can be implemented once in that base class, and you do end up with
the item provider that you want, avoiding the duplicate property
descriptor implementation in derived classes.
> Best Regards,
> Javi
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1128448 is a reply to message #1126145] Mon, 07 October 2013 18:04 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Hi Ed,

comments below.

Ed Merks wrote on Sat, 05 October 2013 09:41
Xavipen,

Comments below.

On 04/10/2013 10:47 PM, Xavipen Mising name wrote:
> Sorry Ed, I did not see your reply.
> First, I will try to clarificate why for my case is useful to have
> Supress Interface to true ( I will get to the Item Providers in a
> minute).
>
> There is a bundle/with a model for a service called Multiplexor. It
> has methods and a couple of attributes.
> However there are more than one implementation for the multiplexor
> service.
Which will all have the same attributes though perhaps different
implementations of the operations.
> In the same bundle you would have MultiplexorFIFO and MultiplexorList
> (just made up names)
Or they could be in other models, it doesn't much matter...
>
> In another bundle you may extend the model to provide another
> implementation of the service. Let´s say MultiplexorPriority
> I would like to only have one interface ( defining the service) and
> three different implementation class with do not need to defined
> additional interfaces.
Though there will be additional factory methods for creating these
additional things.
> These is my reason for selecting Supress interfaces to true. If I
> would select Supress interface false I would have 4 EClass modelled
You do have four EClasses modeled.
> but i would end up with 4 interfaces generated (where i only really
> need one) and implementation classes.
How is Suppress Interfaces related to marking EClass.isInterface
true? You use the latter to force an interface to be generated and
you use the former to eliminate the otherwise empty interfaces?

From your description it sounds like the base EClass has attributes and
that you're duplicating the implementation of those attributes three
times. You could accomplish the same thing as followings (using Xcore
notation)

package org.example

class Base
{
String attribute
op void foo()
}

class Derived1 extends Base wraps Base
{
op void foo()
{
// Do something.
}
}

class Derived2 extends Base wraps Base
{
op void foo()
{
// Do something else.
}
}

I.e., by setting the instanceTypeName of the derived EClasses to the
generated interface of the base EClass, you'll effectively suppress the
generation of an interface for them. But you'll still generate an
implementation class that can still share the common code in the Base
class implementation.



Thanks for the typ on instanceTypeName. I did not know that. I will have a look. The other implementations will have additional specific attributes to configured the beheviour of the specifi implementation.

Quote:

>
>
> Now going to the point of why i see useful the ItemProviders for
> interfaces (this is beside the discussion on whether to have supress
> interfaces to true or not).
> If i would like an extensible application where several different
> implementations should coexist and you do not know before hand which
> this implementations may be, but you want to be able to have a let´s
> say tree view (The example above still valid for this). You could do
> two things:
>
> 1) Set an ComposedAdapterFactory with all the registered adapter
> factories.
>
> This would work but if you have modelled a lot of packages there will
> be a lot of search in adapterFactories that are not needed and you may
> not get an unified view for the multiplexor service, which sometimes
> is what is needed.
No, this statement sounds bogus. There is no significant performance
overhead, and you've overlooked several things. Derived classes may
introduce additional features that one would expect to appear in the
properties view. Also, derived classes should likely display a
different icon so the unified view's user can distinguish the different
behaviors implied by the different implementation classes.


It is true that some implementations would have additional features and that this approach allows for showing then. And it is brilliant the design of EMF in these regard.

My concern here is that the containing all generated adapterFactories generated ( one per package) will search one by one in those adapterFactories till it finds one that feets. At least that is my understanding. So whenever an operation comes to the label provider or content provider these search has to be done again. How expensive is these search in the worst case scenario? (that is that the last AdapterFactory is the one that will suply the itemProvider) Maybe there is some caching done that i have not seen but if it is not, that search takes valuable time.

If there are many notification, in my system could be one million in a second (although i use a system to bunch them to reduce the load) that would mean several searchs are called per second.

This is why it is more important in these case to reduce the searches at the price of having more generics ItemProviders base on interfaces.


Quote:

>
> 2) If ItemProviders would be generated for the interface you could use
> only the ItemAdaptorFactory genereated for the package where your
> interface is. (Multiplexor in this case.) Then you will have a common
> display for all implementation of the services and no need to see for
> regiestered AdapterFactories additional bundles that offer other
> implementations. The plus it that you offer a commen itemProvider for
> all the implementation through the "interfaceItemProvider".
If you define your model as above, you won't have this problem, and
you'll have a single implementation of the attributes as well.
>
> You still would like specialice views base on the implementations
> using the implementation providers and there adapter factories. The
> difference is that now it is a choice which way you show it in your view.
>
> Having the ItemProviders generated for the interfaces has no
> disadvantage and some advantages.
I believe whenever that statement is true, it's also true of the
generated implementation class, and even in the example you outline,
that's the case, i.e., you have attributes and all the associated
reflective scaffolding that's being duplicate because you don't have a
common implementation class. A typical reason for marking something as
an interface is because one expects that interface to be used in
multiple inheritance where it's not the primary inheritance and hence
the implementation class will not be reused by the derived classes; when
that's the case for the model classes, that's also the case for the item
providers, which use the same approach. So simply generating all item
providers might well result in item providers that simply are never used
directly and are simply never the base class for some other item
provider that is actually used.



You are right, multiple inheritance is also used. (Although not mention in the specific example i wrote). Also another reason to define the interfaces is Inversion of Control, mainly but not only for decoupling the execution of a certain task from implementation.

ItemProviders that are forseen that will never could also happend without having the interfaces. Less likely but still could happend, i believe that is why there is an option in the genmodel that allows you to define that an ItemProvider should not be generated by an EClass.
Generating the itemProviders for interfaes just give more tools and more flexibility without a cost and still the beheviour can be controlled to decide to use it one way or another. It does not create a conflict but adds functionality.


Another use would be in the situation where you have different roles that interact with the system.

Role Operator: Should not know the details of the implementations, just what is in the interface. With ItemProviders generated for the interfaces it will be strait forward to generate such a view.

Role Engineer: Has a view with all the details, as he is setting up the system. In these case, the view would be generated using specific ItemProviders (checking on all the registered ones if needed.)

Quote:

> Unless of course there are other issues that i am not aware of.
> Changing the generator to allow this is just removing a couple of
> characters in a method.
Those characters didn't get there accidentally, they were put there
deliberately.


I am sure of it. I did not mean disrepect. Just trying to say that, with my limited knowledged of the framework, the change to generate ItemProviders for interfaces seems to be easy.

Quote:

> Moreover, if you do not one the ItemProviders to be generated in the
> genmodel can be set the ItemProvider to NONE.
> I hope i have explain be better this time.
Yes, but there are several flaws in the arguments and with the approach
you've taken. E.g., the generated factory's create methods for these
derived classes returns what type of thing? With the approach I
outlined above, you end up with something cleaner where you don't end up
with implementation classes visible in your API, you do have a common
base implementation class to avoid duplicate code across derived classes
that can be implemented once in that base class, and you do end up with
the item provider that you want, avoiding the duplicate property
descriptor implementation in derived classes.
>


As you said before, multiple inhertitance is in place, so it is not as easy.

Hummm, i did not considere the create methods, I am just focus on the content/label providers part. I did not have time to look for the command part ( i believe that is the part that would need the create methods)

My first respond to that would be not to generate them as they are interfaces. That would be adding a check clause in the ItemProvider template to skip generating them. So that would not change.

Best Regards,
Javi
Re: EMF Item Providers for interfaces. [message #1128457 is a reply to message #1128448] Mon, 07 October 2013 18:13 Go to previous messageGo to next message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
One clarification, i am not sure i understood what you meant with the create methods. If you meant the create methods in the ItemProviderAdaptorFactory then i see no issue because a MultiplexorItemProvider class (the itemprovider for the interface) would have been created and that is what would be return in the create method.

Please, let me know if i am missing something.

Re: EMF Item Providers for interfaces. [message #1128986 is a reply to message #1128448] Tue, 08 October 2013 07:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Xavipen,

Comments below.

On 07/10/2013 8:04 PM, Xavipen Mising name wrote:
> Hi Ed,
>
> comments below.
>
> Ed Merks wrote on Sat, 05 October 2013 09:41
>> Xavipen,
>>
>> Comments below.
>>
>> On 04/10/2013 10:47 PM, Xavipen Mising name wrote:
>> > Sorry Ed, I did not see your reply.
>> > First, I will try to clarificate why for my case is useful to have
>> > Supress Interface to true ( I will get to the Item Providers in a >
>> minute).
>> >
>> > There is a bundle/with a model for a service called Multiplexor. It
>> > has methods and a couple of attributes.
>> > However there are more than one implementation for the multiplexor
>> > service.
>> Which will all have the same attributes though perhaps different
>> implementations of the operations.
>> > In the same bundle you would have MultiplexorFIFO and
>> MultiplexorList > (just made up names)
>> Or they could be in other models, it doesn't much matter...
>> >
>> > In another bundle you may extend the model to provide another >
>> implementation of the service. Let´s say MultiplexorPriority
>> > I would like to only have one interface ( defining the service) and
>> > three different implementation class with do not need to defined >
>> additional interfaces. Though there will be additional factory
>> methods for creating these additional things.
>> > These is my reason for selecting Supress interfaces to true. If I >
>> would select Supress interface false I would have 4 EClass modelled
>> You do have four EClasses modeled.
>> > but i would end up with 4 interfaces generated (where i only really
>> > need one) and implementation classes.
>> How is Suppress Interfaces related to marking EClass.isInterface
>> true? You use the latter to force an interface to be generated and
>> you use the former to eliminate the otherwise empty interfaces?
>>
>> From your description it sounds like the base EClass has attributes
>> and that you're duplicating the implementation of those attributes
>> three times. You could accomplish the same thing as followings
>> (using Xcore notation)
>>
>> package org.example
>>
>> class Base
>> {
>> String attribute
>> op void foo()
>> }
>>
>> class Derived1 extends Base wraps Base
>> {
>> op void foo()
>> {
>> // Do something.
>> }
>> }
>>
>> class Derived2 extends Base wraps Base
>> {
>> op void foo()
>> {
>> // Do something else.
>> }
>> }
>>
>> I.e., by setting the instanceTypeName of the derived EClasses to the
>> generated interface of the base EClass, you'll effectively suppress
>> the generation of an interface for them. But you'll still generate
>> an implementation class that can still share the common code in the
>> Base class implementation.
>
>
> Thanks for the typ on instanceTypeName. I did not know that. I will
> have a look. The other implementations will have additional specific
> attributes to configured the beheviour of the specifi implementation.
That's what I figured.
>
> Quote:
>> >
>> >
>> > Now going to the point of why i see useful the ItemProviders for >
>> interfaces (this is beside the discussion on whether to have supress
>> > interfaces to true or not).
>> > If i would like an extensible application where several different >
>> implementations should coexist and you do not know before hand which
>> > this implementations may be, but you want to be able to have a
>> let´s > say tree view (The example above still valid for this). You
>> could do > two things:
>> >
>> > 1) Set an ComposedAdapterFactory with all the registered adapter >
>> factories.
>> >
>> > This would work but if you have modelled a lot of packages there
>> will > be a lot of search in adapterFactories that are not needed and
>> you may > not get an unified view for the multiplexor service, which
>> sometimes > is what is needed.
>> No, this statement sounds bogus. There is no significant performance
>> overhead, and you've overlooked several things. Derived classes may
>> introduce additional features that one would expect to appear in the
>> properties view. Also, derived classes should likely display a
>> different icon so the unified view's user can distinguish the
>> different behaviors implied by the different implementation classes.
>
>
> It is true that some implementations would have additional features
> and that this approach allows for showing then.
That's what I figured as well, and of course those implementations need
additional API for manipulating those features...
> And it is brilliant the design of EMF in these regard.
> My concern here is that the containing all generated adapterFactories
> generated ( one per package) will search one by one in those
> adapterFactories till it finds one that feets.
Why be concerned abstractly? You can look in the debugger how it works
and you can measure with a profiler whether there is any cause for
concern, but never have I seen the dispatching to the adapter factory
being a significant contributor to the overall performance lag.
> At least that is my understanding. So whenever an operation comes to
> the label provider or content provider these search has to be done again.
I strongly advise against hypothetical performance concerns.
> How expensive is these search in the worst case scenario?
That's exactly the point, why are you concerned about this and not the
10,000 other things you might be concerned about? Let measurements
drive your concern, you'll inevitably find the problems are not where
you'd expect them.
> (that is that the last AdapterFactory is the one that will suply the
> itemProvider) Maybe there is some caching done that i have not seen
> but if it is not, that search takes valuable time.
How much? What % of the time is spent in the composed adapter factory
dispatching to the correct generated item provider adapter factory?
> If there are many notification, in my system could be one million in a
> second (although i use a system to bunch them to reduce the load) that
> would mean several searchs are called per second.
Why do notifications cause a search?
>
> This is why it is more important in these case to reduce the searches
> at the price of having more generics ItemProviders base on interfaces.
This sounds entirely hypothetical with no basis in actual measurements.
If this were to become a problem (and I can't imagine that being the
case), you could create an efficient map from EClass to the necessary
factory, or even from EClass to the necessary singleton item provider
adapter...
>
> Quote:
>> >
>> > 2) If ItemProviders would be generated for the interface you could
>> use > only the ItemAdaptorFactory genereated for the package where
>> your > interface is. (Multiplexor in this case.) Then you will have a
>> common > display for all implementation of the services and no need
>> to see for > regiestered AdapterFactories additional bundles that
>> offer other > implementations. The plus it that you offer a commen
>> itemProvider for > all the implementation through the
>> "interfaceItemProvider".
>> If you define your model as above, you won't have this problem, and
>> you'll have a single implementation of the attributes as well.
>> >
>> > You still would like specialice views base on the implementations >
>> using the implementation providers and there adapter factories. The >
>> difference is that now it is a choice which way you show it in your
>> view.
>> >
>> > Having the ItemProviders generated for the interfaces has no >
>> disadvantage and some advantages. I believe whenever that statement
>> is true, it's also true of the generated implementation class, and
>> even in the example you outline, that's the case, i.e., you have
>> attributes and all the associated reflective scaffolding that's being
>> duplicate because you don't have a common implementation class. A
>> typical reason for marking something as an interface is because one
>> expects that interface to be used in multiple inheritance where it's
>> not the primary inheritance and hence the implementation class will
>> not be reused by the derived classes; when that's the case for the
>> model classes, that's also the case for the item providers, which use
>> the same approach. So simply generating all item providers might
>> well result in item providers that simply are never used directly and
>> are simply never the base class for some other item provider that is
>> actually used.
>
>
> You are right, multiple inheritance is also used. (Although not
> mention in the specific example i wrote). Also another reason to
> define the interfaces is Inversion of Control, mainly but not only for
> decoupling the execution of a certain task from implementation.
Well, you always get interfaces, but the issue is why do you want only
interfaces and no reusable implementation class...
>
> ItemProviders that are forseen that will never could also happend
> without having the interfaces.
Indeed, but as I said, if you expect to have an implementation class
that won't be used or reused via inheritance so you define it to not
have an implementation class, I expect you'll therefore also have an
item provider class that won't be used or reused via inheritance.
> Less likely but still could happend,
Why less likely? Equally likely I'd say.
> i believe that is why there is an option in the genmodel that allows
> you to define that an ItemProvider should not be generated by an EClass.
> Generating the itemProviders for interfaes just give more tools and
> more flexibility without a cost
It certainly wouldn't be appropriate to change the default so all
existing client end up with item providers they didn't have and likely
don't need unless they actively start changing the flags in the GenModel
to get back the old behavior.
> and still the beheviour can be controlled to decide to use it one way
> or another. It does not create a conflict but adds functionality.
>
>
> Another use would be in the situation where you have different roles
> that interact with the system.
You keep inventing hypothetical use cases when your real use case hasn't
proven to be a strong argument in favor of what you're suggesting. In
the time you spent on this, you could have try the simple suggestion
that would have achieved what you need in your real use case more
cleanly than the approach you've taken, which seems to hinge on EMF
making modifications.
>
> Role Operator: Should not know the details of the implementations,
> just what is in the interface. With ItemProviders generated for the
> interfaces it will be strait forward to generate such a view.
The item provider only generate useful things if there are modeled
features...
>
> Role Engineer: Has a view with all the details, as he is setting up
> the system. In these case, the view would be generated using specific
> ItemProviders (checking on all the registered ones if needed.)
That will always be necessary if the implementation of the interface
requires any additional features...
>
> Quote:
>> > Unless of course there are other issues that i am not aware of. >
>> Changing the generator to allow this is just removing a couple of >
>> characters in a method. Those characters didn't get there
>> accidentally, they were put there deliberately.
>
>
> I am sure of it. I did not mean disrepect. Just trying to say that,
> with my limited knowledged of the framework, the change to generate
> ItemProviders for interfaces seems to be easy.
Yes, and when we initialize a GenModel could set that property to turn
off generation by default, but it's not what we do now, so changes leave
us with disruptive behavior for existing clients, which we try to avoid
unless there are compelling reasons...
>
> Quote:
>> > Moreover, if you do not one the ItemProviders to be generated in
>> the > genmodel can be set the ItemProvider to NONE.
>> > I hope i have explain be better this time. Yes, but there are
>> several flaws in the arguments and with the approach you've taken.
>> E.g., the generated factory's create methods for these derived
>> classes returns what type of thing? With the approach I outlined
>> above, you end up with something cleaner where you don't end up with
>> implementation classes visible in your API, you do have a common base
>> implementation class to avoid duplicate code across derived classes
>> that can be implemented once in that base class, and you do end up
>> with the item provider that you want, avoiding the duplicate property
>> descriptor implementation in derived classes.
>> >
>
>
> As you said before, multiple inhertitance is in place, so it is not as
> easy.
>
> Hummm, i did not considere the create methods, I am just focus on the
> content/label providers part. I did not have time to look for the
> command part ( i believe that is the part that would need the create
> methods)
>
> My first respond to that would be not to generate them as they are
> interfaces.
The create methods in the model factory are necessary for creating the
appropriate instance and you can't do without them.
> That would be adding a check clause in the ItemProvider template to
> skip generating them. So that would not change.
See how much you seem to hinge on wanting changes in the framework. Try
what I suggested and you'll see it works better than the approach you've
taken.
>
> Best Regards,
> Javi


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Item Providers for interfaces. [message #1134326 is a reply to message #1128986] Sat, 12 October 2013 12:05 Go to previous message
Xavipen Mising name is currently offline Xavipen Mising nameFriend
Messages: 59
Registered: March 2011
Member
Hi Ed,

I`ve been again side track, so i can not continue playing around with the Edit framework. When i have time again i will try to do sometests in that direction.

My intention has been to put out there several use cases where having a ItemProvider generated for interfaces is useful. Not only for my particular case. I understand that are more to the eye than just allowing to generated the interfaces, but at the same time i think that generating those ItemProviders will make the framework event more flexible. I will be happy to help in add/implement this, if you ever consider that is worth the effort.

In the meantime i may try to check the example to extend the code generator with its extension points. To generate the ItemProviders for the interfaces. Unfortunatelly i think i will not have any time for this till December Sad

Note: For backward compatibility in beheviour i guess that the genmodel that is load from an ecore model should initialize the ItemProvider generation for EClasses with interface set to true to NONE instead of Singleton

Cheers,
Javi
Previous Topic:Modify an EMF model programmatically
Next Topic:How to transform an ecore model into code/artifacts?
Goto Forum:
  


Current Time: Fri Mar 29 14:08:47 GMT 2024

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

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

Back to the top