Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EEF ComposedAdapterFactory
| | | |
| Re: EEF ComposedAdapterFactory [message #513375 is a reply to message #513247] |
Tue, 09 February 2010 21:46   |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Ed, Goulwen,
Yes, and in general one of the really nice things about the EMF generated stuff is how it follows the EMF model hierarchy so that you can selectively override behavior for the whole set. A couple of years back there was a feature request completed that allows users to specify the common base class for the ItemProviders. All really nice for overrding generic behavior and something to take a look at perhaps for EEF.
But actually this brings up something I've been curious about for some time now, and it might be an idiosyncrasy / mistake in how I have things set up. But I'm wondering then why the EMF generated editor for example does:
protected void initializeEditingDomain() {
// Create an adapter factory that yields item providers.
//
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Registry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MainPackageItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new SubPackage1 ItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new SubPackage1 ItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new ReflectiveItemProviderAdapterFactory());
When I take those out of the editor, it fails to find any of the adapters. So perhaps they haven't been registered correctly? But then why is this code generated?
And sorry for all those bug reports! It's because I love EEF that I file them. 
cheers,
Miles
| Goulwen Le Fur wrote on Tue, 09 February 2010 03:58 | Yes Ed, I think it's what is done but I think that the need of Miles is
to override the default behavior (i.e. the behaviour of the registered
adapter factory). And for the moment, it's not very easy to do that in
EEF
Thx
--
Goulwen
Ed Merks a écrit :
> Goulwen,
>
> Note that creating the factory instance with
>
> new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
> ensures that any register item provider adapter factory is automatically
> used.
>
>
> Goulwen Le Fur wrote:
>> Hi Miles,
>>
>> Thanks for your very interesting feedback. You're right about our
>> strategy for AdapterFactories. This isn't very satisfactory. We plan
>> to make a real improvment in the views (it includes the way to defines
>> adapter factories) but before that, we have a really important thing
>> to do: create Non-regression Tests.
>>
>> We currently work on creating these tests and I hope we will finish
>> this week.
>>
>> We will begin this phase of refund after.
>>
>> Now I will check the bugs you open on EEF 
>>
|
|
|
|
| Re: EEF ComposedAdapterFactory [message #513377 is a reply to message #513375] |
Tue, 09 February 2010 21:54 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
>
> Ed, Goulwen,
>
> Yes, and in general one of the really nice things about the EMF
> generated stuff is how it follows the EMF model hierarchy so that you
> can selectively override behavior for the whole set. A couple of years
> back there was a feature request completed that allows users to
> specify the common base class for the ItemProviders. All really nice
> for overrding generic behavior and something to take a look at perhaps
> for EEF.
>
> But actually this brings up something I've been curious about for some
> time now, and it might be an idiosyncrasy / mistake in how I have
> things set up. But I'm wondering then why the EMF generated editor for
> example does:
>
> protected void initializeEditingDomain() {
> // Create an adapter factory that yields item providers.
> //
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
Support for a registry didn't always exist. It was added at some point
along the way.
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
This one isn't registered, so it's really needed.
> adapterFactory.addAdapterFactory(new
> MainPackageItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
These three should be registered. Are there typos here because of
duplicates? Check the plugin.xml for the *.edit projects to verify
they're registered.
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
This one isn't registered either, so it's really needed.
>
>
> When I take those out of the editor, it fails to find any of the
> adapters. So perhaps they haven't been registered correctly? But then
> why is this code generated?
It could be changed to omit them but given it's a generated editor for
the package, one can assume it's always needed and add it explicitly.
>
>
> And sorry for all those bug reports! It's because I love EEF that I
> file them. :)
>
> cheers,
>
> Miles
>
>
> Goulwen Le Fur wrote on Tue, 09 February 2010 03:58
>> Yes Ed, I think it's what is done but I think that the need of Miles
>> is to override the default behavior (i.e. the behaviour of the
>> registered adapter factory). And for the moment, it's not very easy
>> to do that in EEF :)
>>
>> Thx
>>
>> --
>> Goulwen
>>
>> Ed Merks a écrit :
>> > Goulwen,
>> > > Note that creating the factory instance with
>> > > new
>> > ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg
>> istry.INSTANCE);
>> > > ensures that any register item provider adapter factory is
>> automatically > used.
>> > > > Goulwen Le Fur wrote:
>> >> Hi Miles,
>> >>
>> >> Thanks for your very interesting feedback. You're right about our
>> >> strategy for AdapterFactories. This isn't very satisfactory. We
>> plan >> to make a real improvment in the views (it includes the way
>> to defines >> adapter factories) but before that, we have a really
>> important thing >> to do: create Non-regression Tests.
>> >>
>> >> We currently work on creating these tests and I hope we will
>> finish >> this week.
>> >>
>> >> We will begin this phase of refund after.
>> >>
>> >> Now I will check the bugs you open on EEF ;)
>> >>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EEF ComposedAdapterFactory [message #513388 is a reply to message #513377] |
Tue, 09 February 2010 23:12 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Okay, Ed thanks for clarifying. Please see my responses below.
| Ed Merks wrote on Tue, 09 February 2010 16:54 |
Miles Parker wrote:
>
> Ed, Goulwen,
>
> Yes, and in general one of the really nice things about the EMF
> generated stuff is how it follows the EMF model hierarchy so that you
> can selectively override behavior for the whole set. A couple of years
> back there was a feature request completed that allows users to
> specify the common base class for the ItemProviders. All really nice
> for overrding generic behavior and something to take a look at perhaps
> for EEF.
>
> But actually this brings up something I've been curious about for some
> time now, and it might be an idiosyncrasy / mistake in how I have
> things set up. But I'm wondering then why the EMF generated editor for
> example does:
>
> protected void initializeEditingDomain() {
> // Create an adapter factory that yields item providers.
> //
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
Support for a registry didn't always exist. It was added at some point
along the way.
|
Yeah, that has been my default assumption. Then, as I started building my own ItemProvider editors (super easy!) a while ago I noticed that I needed them there as well, so I got confused.
| Quote: |
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
This one isn't registered, so it's really needed.
> adapterFactory.addAdapterFactory(new
> MainPackageItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
These three should be registered. Are there typos here because of
duplicates? Check the plugin.xml for the *.edit projects to verify
they're registered.
|
Sorry, screwed up in my attempt to make the example general. Here is the *actual* code in ..acore:
protected void initializeEditingDomain() {
// Create an adapter factory that yields item providers.
//
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Registry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMFunctionItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMActItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new ReflectiveItemProviderAdapterFactory());
...
And this is the ..acore.edit plugin.xml
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/structure"
class = "org.metaabm.provider.MetaABMItemProviderAdapterFactory"
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/act"
class = "org.metaabm.act.provider.MetaABMActItemProviderAdapterFactory"
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/function"
class = "org.metaabm.function.provider.MetaABMFunctionItemProviderAdapterFactory"
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
So on inspection that al seems correct. Now I've heavily customized the generated editor, so it's possible that I've stepped on something. OTOH, I have done a compare against a generated editor and I didn't see anything obviously messed up.
And as a BTW, I noticed a while back that the base package also has this:
public static AdapterFactory getGenericAdapterFactory() {
if (genericFactory == null) {
List<AdapterFactory> factories = new ArrayList<AdapterFactory>();
factories.add(new ResourceItemProviderAdapterFactory());
factories.add(new MetaABMItemProviderAdapterFactory());
factories.add(new MetaABMActItemProviderAdapterFactory());
factories.add(new MetaABMFunctionItemProviderAdapterFactory());
factories.add(new ReflectiveItemProviderAdapterFactory());
genericFactory = new ComposedAdapterFactory(factories);
}
return genericFactory;
}
So I've begun to try to use that so there is a single point of maintenance..
| Quote: |
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
This one isn't registered either, so it's really needed.
>
>
> When I take those out of the editor, it fails to find any of the
> adapters. So perhaps they haven't been registered correctly? But then
> why is this code generated?
It could be changed to omit them but given it's a generated editor for
the package, one can assume it's always needed and add it explicitly.
|
Makes sense.
|
|
|
| Re: EEF ComposedAdapterFactory [message #513491 is a reply to message #513388] |
Wed, 10 February 2010 06:50 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Miles,
I don't know what this is?
public static AdapterFactory getGenericAdapterFactory() {
if (genericFactory == null) {
List<AdapterFactory> factories = new
ArrayList<AdapterFactory>();
factories.add(new ResourceItemProviderAdapterFactory());
factories.add(new MetaABMItemProviderAdapterFactory());
factories.add(new MetaABMActItemProviderAdapterFactory());
factories.add(new MetaABMFunctionItemProviderAdapterFactory());
factories.add(new ReflectiveItemProviderAdapterFactory());
genericFactory = new ComposedAdapterFactory(factories);
}
return genericFactory;
}
But note that the composed factory isn't created with the registry so
will need explicit registration.
Miles Parker wrote:
>
> Okay, Ed thanks for clarifying. Please see my responses below.
>
> Ed Merks wrote on Tue, 09 February 2010 16:54
>> Miles Parker wrote:
>> >
>> > Ed, Goulwen,
>> >
>> > Yes, and in general one of the really nice things about the EMF >
>> generated stuff is how it follows the EMF model hierarchy so that you
>> > can selectively override behavior for the whole set. A couple of
>> years > back there was a feature request completed that allows users
>> to > specify the common base class for the ItemProviders. All really
>> nice > for overrding generic behavior and something to take a look at
>> perhaps > for EEF.
>> >
>> > But actually this brings up something I've been curious about for
>> some > time now, and it might be an idiosyncrasy / mistake in how I
>> have > things set up. But I'm wondering then why the EMF generated
>> editor for > example does:
>> >
>> > protected void initializeEditingDomain() {
>> > // Create an adapter factory that yields item providers.
>> > //
>> > adapterFactory = new >
>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg
>> istry.INSTANCE); >
>> Support for a registry didn't always exist. It was added at some
>> point along the way.
>
>
> Yeah, that has been my default assumption. Then, as I started building
> my own ItemProvider editors (super easy!) a while ago I noticed that I
> needed them there as well, so I got confused.
>
> Quote:
>> >
>> > adapterFactory.addAdapterFactory(new >
>> ResourceItemProviderAdapterFactory());
>> This one isn't registered, so it's really needed.
>> > adapterFactory.addAdapterFactory(new >
>> MainPackageItemProviderAdapterFactory());
>> > adapterFactory.addAdapterFactory(new SubPackage1 >
>> ItemProviderAdapterFactory());
>> > adapterFactory.addAdapterFactory(new SubPackage1 >
>> ItemProviderAdapterFactory());
>> These three should be registered. Are there typos here because of
>> duplicates? Check the plugin.xml for the *.edit projects to verify
>> they're registered.
>
>
> Sorry, screwed up in my attempt to make the example general. Here is
> the *actual* code in ..acore:
>
>
> protected void initializeEditingDomain() {
> // Create an adapter factory that yields item providers.
> //
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMFunctionItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMActItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
> ..
>
>
> And this is the ..acore.edit plugin.xml
>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/structure" class =
> "org.metaabm.provider.MetaABMItemProviderAdapterFactory"
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/act" class =
> " org.metaabm.act.provider.MetaABMActItemProviderAdapterFactor y "
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/function" class =
> " org.metaabm.function.provider.MetaABMFunctionItemProviderAda pterFactory "
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
>
> So on inspection that al seems correct. Now I've heavily customized
> the generated editor, so it's possible that I've stepped on something.
> OTOH, I have done a compare against a generated editor and I didn't
> see anything obviously messed up.
>
> And as a BTW, I noticed a while back that the base package also has this:
>
>
> public static AdapterFactory getGenericAdapterFactory() {
> if (genericFactory == null) {
> List<AdapterFactory> factories = new
> ArrayList<AdapterFactory>();
> factories.add(new ResourceItemProviderAdapterFactory());
> factories.add(new MetaABMItemProviderAdapterFactory());
> factories.add(new MetaABMActItemProviderAdapterFactory());
> factories.add(new
> MetaABMFunctionItemProviderAdapterFactory());
> factories.add(new ReflectiveItemProviderAdapterFactory());
> genericFactory = new ComposedAdapterFactory(factories);
> }
> return genericFactory;
> }
>
>
> So I've begun to try to use that so there is a single point of
> maintenance..
>
> Quote:
>> > adapterFactory.addAdapterFactory(new >
>> ReflectiveItemProviderAdapterFactory());
>> This one isn't registered either, so it's really needed.
>> >
>> >
>> > When I take those out of the editor, it fails to find any of the >
>> adapters. So perhaps they haven't been registered correctly? But then
>> > why is this code generated?
>> It could be changed to omit them but given it's a generated editor
>> for the package, one can assume it's always needed and add it
>> explicitly.
>
>
> Makes sense.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
| Re: EEF ComposedAdapterFactory [message #622108 is a reply to message #622106] |
Tue, 09 February 2010 21:46 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Ed, Goulwen,
Yes, and in general one of the really nice things about the EMF generated stuff is how it follows the EMF model hierarchy so that you can selectively override behavior for the whole set. A couple of years back there was a feature request completed that allows users to specify the common base class for the ItemProviders. All really nice for overrding generic behavior and something to take a look at perhaps for EEF.
But actually this brings up something I've been curious about for some time now, and it might be an idiosyncrasy / mistake in how I have things set up. But I'm wondering then why the EMF generated editor for example does:
protected void initializeEditingDomain() {
// Create an adapter factory that yields item providers.
//
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MainPackageItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new SubPackage1 ItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new SubPackage1 ItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new ReflectiveItemProviderAdapterFactory());
When I take those out of the editor, it fails to find any of the adapters. So perhaps they haven't been registered correctly? But then why is this code generated?
And sorry for all those bug reports! It's because I love EEF that I file them. :)
cheers,
Miles
Goulwen Le Fur wrote on Tue, 09 February 2010 03:58
> Yes Ed, I think it's what is done but I think that the need of Miles is
> to override the default behavior (i.e. the behaviour of the registered
> adapter factory). And for the moment, it's not very easy to do that in
> EEF :)
>
> Thx
>
> --
> Goulwen
>
> Ed Merks a écrit :
> > Goulwen,
> >
> > Note that creating the factory instance with
> >
> > new
> > ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
> >
> > ensures that any register item provider adapter factory is automatically
> > used.
> >
> >
> > Goulwen Le Fur wrote:
> >> Hi Miles,
> >>
> >> Thanks for your very interesting feedback. You're right about our
> >> strategy for AdapterFactories. This isn't very satisfactory. We plan
> >> to make a real improvment in the views (it includes the way to defines
> >> adapter factories) but before that, we have a really important thing
> >> to do: create Non-regression Tests.
> >>
> >> We currently work on creating these tests and I hope we will finish
> >> this week.
> >>
> >> We will begin this phase of refund after.
> >>
> >> Now I will check the bugs you open on EEF ;)
> >>
|
|
|
| Re: EEF ComposedAdapterFactory [message #622109 is a reply to message #513375] |
Tue, 09 February 2010 21:54 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
>
> Ed, Goulwen,
>
> Yes, and in general one of the really nice things about the EMF
> generated stuff is how it follows the EMF model hierarchy so that you
> can selectively override behavior for the whole set. A couple of years
> back there was a feature request completed that allows users to
> specify the common base class for the ItemProviders. All really nice
> for overrding generic behavior and something to take a look at perhaps
> for EEF.
>
> But actually this brings up something I've been curious about for some
> time now, and it might be an idiosyncrasy / mistake in how I have
> things set up. But I'm wondering then why the EMF generated editor for
> example does:
>
> protected void initializeEditingDomain() {
> // Create an adapter factory that yields item providers.
> //
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
Support for a registry didn't always exist. It was added at some point
along the way.
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
This one isn't registered, so it's really needed.
> adapterFactory.addAdapterFactory(new
> MainPackageItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new SubPackage1
> ItemProviderAdapterFactory());
These three should be registered. Are there typos here because of
duplicates? Check the plugin.xml for the *.edit projects to verify
they're registered.
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
This one isn't registered either, so it's really needed.
>
>
> When I take those out of the editor, it fails to find any of the
> adapters. So perhaps they haven't been registered correctly? But then
> why is this code generated?
It could be changed to omit them but given it's a generated editor for
the package, one can assume it's always needed and add it explicitly.
>
>
> And sorry for all those bug reports! It's because I love EEF that I
> file them. :)
>
> cheers,
>
> Miles
>
>
> Goulwen Le Fur wrote on Tue, 09 February 2010 03:58
>> Yes Ed, I think it's what is done but I think that the need of Miles
>> is to override the default behavior (i.e. the behaviour of the
>> registered adapter factory). And for the moment, it's not very easy
>> to do that in EEF :)
>>
>> Thx
>>
>> --
>> Goulwen
>>
>> Ed Merks a écrit :
>> > Goulwen,
>> > > Note that creating the factory instance with
>> > > new
>> > ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg
>> istry.INSTANCE);
>> > > ensures that any register item provider adapter factory is
>> automatically > used.
>> > > > Goulwen Le Fur wrote:
>> >> Hi Miles,
>> >>
>> >> Thanks for your very interesting feedback. You're right about our
>> >> strategy for AdapterFactories. This isn't very satisfactory. We
>> plan >> to make a real improvment in the views (it includes the way
>> to defines >> adapter factories) but before that, we have a really
>> important thing >> to do: create Non-regression Tests.
>> >>
>> >> We currently work on creating these tests and I hope we will
>> finish >> this week.
>> >>
>> >> We will begin this phase of refund after.
>> >>
>> >> Now I will check the bugs you open on EEF ;)
>> >>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EEF ComposedAdapterFactory [message #622110 is a reply to message #513377] |
Tue, 09 February 2010 23:12 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Okay, Ed thanks for clarifying. Please see my responses below.
Ed Merks wrote on Tue, 09 February 2010 16:54
> Miles Parker wrote:
> >
> > Ed, Goulwen,
> >
> > Yes, and in general one of the really nice things about the EMF
> > generated stuff is how it follows the EMF model hierarchy so that you
> > can selectively override behavior for the whole set. A couple of years
> > back there was a feature request completed that allows users to
> > specify the common base class for the ItemProviders. All really nice
> > for overrding generic behavior and something to take a look at perhaps
> > for EEF.
> >
> > But actually this brings up something I've been curious about for some
> > time now, and it might be an idiosyncrasy / mistake in how I have
> > things set up. But I'm wondering then why the EMF generated editor for
> > example does:
> >
> > protected void initializeEditingDomain() {
> > // Create an adapter factory that yields item providers.
> > //
> > adapterFactory = new
> > ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
> >
> Support for a registry didn't always exist. It was added at some point
> along the way.
Yeah, that has been my default assumption. Then, as I started building my own ItemProvider editors (super easy!) a while ago I noticed that I needed them there as well, so I got confused.
Quote:
> >
> > adapterFactory.addAdapterFactory(new
> > ResourceItemProviderAdapterFactory());
> This one isn't registered, so it's really needed.
> > adapterFactory.addAdapterFactory(new
> > MainPackageItemProviderAdapterFactory());
> > adapterFactory.addAdapterFactory(new SubPackage1
> > ItemProviderAdapterFactory());
> > adapterFactory.addAdapterFactory(new SubPackage1
> > ItemProviderAdapterFactory());
> These three should be registered. Are there typos here because of
> duplicates? Check the plugin.xml for the *.edit projects to verify
> they're registered.
Sorry, screwed up in my attempt to make the example general. Here is the *actual* code in ..acore:
protected void initializeEditingDomain() {
// Create an adapter factory that yields item providers.
//
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMFunctionItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MetaABMActItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new ReflectiveItemProviderAdapterFactory());
...
And this is the ..acore.edit plugin.xml
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/structure"
class = "org.metaabm.provider.MetaABMItemProviderAdapterFactory"
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/act"
class = " org.metaabm.act.provider.MetaABMActItemProviderAdapterFactor y "
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
<extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
<factory
uri = "http://metaabm.org/function"
class = " org.metaabm.function.provider.MetaABMFunctionItemProviderAda pterFactory "
supportedTypes =
"org.eclipse.emf.edit.provider.IEditingDomainItemProvider
org.eclipse.emf.edit.provider.IStructuredItemContentProvider
org.eclipse.emf.edit.provider.ITreeItemContentProvider
org.eclipse.emf.edit.provider.IItemLabelProvider
org.eclipse.emf.edit.provider.IItemPropertySource" />
</extension>
So on inspection that al seems correct. Now I've heavily customized the generated editor, so it's possible that I've stepped on something. OTOH, I have done a compare against a generated editor and I didn't see anything obviously messed up.
And as a BTW, I noticed a while back that the base package also has this:
public static AdapterFactory getGenericAdapterFactory() {
if (genericFactory == null) {
List<AdapterFactory> factories = new ArrayList<AdapterFactory>();
factories.add(new ResourceItemProviderAdapterFactory());
factories.add(new MetaABMItemProviderAdapterFactory());
factories.add(new MetaABMActItemProviderAdapterFactory());
factories.add(new MetaABMFunctionItemProviderAdapterFactory());
factories.add(new ReflectiveItemProviderAdapterFactory());
genericFactory = new ComposedAdapterFactory(factories);
}
return genericFactory;
}
So I've begun to try to use that so there is a single point of maintenance..
Quote:
> > adapterFactory.addAdapterFactory(new
> > ReflectiveItemProviderAdapterFactory());
> This one isn't registered either, so it's really needed.
> >
> >
> > When I take those out of the editor, it fails to find any of the
> > adapters. So perhaps they haven't been registered correctly? But then
> > why is this code generated?
> It could be changed to omit them but given it's a generated editor for
> the package, one can assume it's always needed and add it explicitly.
Makes sense.
|
|
|
| Re: EEF ComposedAdapterFactory [message #622111 is a reply to message #513388] |
Wed, 10 February 2010 11:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Miles,
I don't know what this is?
public static AdapterFactory getGenericAdapterFactory() {
if (genericFactory == null) {
List<AdapterFactory> factories = new
ArrayList<AdapterFactory>();
factories.add(new ResourceItemProviderAdapterFactory());
factories.add(new MetaABMItemProviderAdapterFactory());
factories.add(new MetaABMActItemProviderAdapterFactory());
factories.add(new MetaABMFunctionItemProviderAdapterFactory());
factories.add(new ReflectiveItemProviderAdapterFactory());
genericFactory = new ComposedAdapterFactory(factories);
}
return genericFactory;
}
But note that the composed factory isn't created with the registry so
will need explicit registration.
Miles Parker wrote:
>
> Okay, Ed thanks for clarifying. Please see my responses below.
>
> Ed Merks wrote on Tue, 09 February 2010 16:54
>> Miles Parker wrote:
>> >
>> > Ed, Goulwen,
>> >
>> > Yes, and in general one of the really nice things about the EMF >
>> generated stuff is how it follows the EMF model hierarchy so that you
>> > can selectively override behavior for the whole set. A couple of
>> years > back there was a feature request completed that allows users
>> to > specify the common base class for the ItemProviders. All really
>> nice > for overrding generic behavior and something to take a look at
>> perhaps > for EEF.
>> >
>> > But actually this brings up something I've been curious about for
>> some > time now, and it might be an idiosyncrasy / mistake in how I
>> have > things set up. But I'm wondering then why the EMF generated
>> editor for > example does:
>> >
>> > protected void initializeEditingDomain() {
>> > // Create an adapter factory that yields item providers.
>> > //
>> > adapterFactory = new >
>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg
>> istry.INSTANCE); >
>> Support for a registry didn't always exist. It was added at some
>> point along the way.
>
>
> Yeah, that has been my default assumption. Then, as I started building
> my own ItemProvider editors (super easy!) a while ago I noticed that I
> needed them there as well, so I got confused.
>
> Quote:
>> >
>> > adapterFactory.addAdapterFactory(new >
>> ResourceItemProviderAdapterFactory());
>> This one isn't registered, so it's really needed.
>> > adapterFactory.addAdapterFactory(new >
>> MainPackageItemProviderAdapterFactory());
>> > adapterFactory.addAdapterFactory(new SubPackage1 >
>> ItemProviderAdapterFactory());
>> > adapterFactory.addAdapterFactory(new SubPackage1 >
>> ItemProviderAdapterFactory());
>> These three should be registered. Are there typos here because of
>> duplicates? Check the plugin.xml for the *.edit projects to verify
>> they're registered.
>
>
> Sorry, screwed up in my attempt to make the example general. Here is
> the *actual* code in ..acore:
>
>
> protected void initializeEditingDomain() {
> // Create an adapter factory that yields item providers.
> //
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMFunctionItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> MetaABMActItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
> ..
>
>
> And this is the ..acore.edit plugin.xml
>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/structure" class =
> "org.metaabm.provider.MetaABMItemProviderAdapterFactory"
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/act" class =
> " org.metaabm.act.provider.MetaABMActItemProviderAdapterFactor y "
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
> <extension point="org.eclipse.emf.edit.itemProviderAdapterFactories">
> <factory uri = "http://metaabm.org/function" class =
> " org.metaabm.function.provider.MetaABMFunctionItemProviderAda pterFactory "
> supportedTypes =
> "org.eclipse.emf.edit.provider.IEditingDomainItemProvider
> org.eclipse.emf.edit.provider.IStructuredItemContentProvider
> org.eclipse.emf.edit.provider.ITreeItemContentProvider
> org.eclipse.emf.edit.provider.IItemLabelProvider
> org.eclipse.emf.edit.provider.IItemPropertySource" />
> </extension>
>
>
> So on inspection that al seems correct. Now I've heavily customized
> the generated editor, so it's possible that I've stepped on something.
> OTOH, I have done a compare against a generated editor and I didn't
> see anything obviously messed up.
>
> And as a BTW, I noticed a while back that the base package also has this:
>
>
> public static AdapterFactory getGenericAdapterFactory() {
> if (genericFactory == null) {
> List<AdapterFactory> factories = new
> ArrayList<AdapterFactory>();
> factories.add(new ResourceItemProviderAdapterFactory());
> factories.add(new MetaABMItemProviderAdapterFactory());
> factories.add(new MetaABMActItemProviderAdapterFactory());
> factories.add(new
> MetaABMFunctionItemProviderAdapterFactory());
> factories.add(new ReflectiveItemProviderAdapterFactory());
> genericFactory = new ComposedAdapterFactory(factories);
> }
> return genericFactory;
> }
>
>
> So I've begun to try to use that so there is a single point of
> maintenance..
>
> Quote:
>> > adapterFactory.addAdapterFactory(new >
>> ReflectiveItemProviderAdapterFactory());
>> This one isn't registered either, so it's really needed.
>> >
>> >
>> > When I take those out of the editor, it fails to find any of the >
>> adapters. So perhaps they haven't been registered correctly? But then
>> > why is this code generated?
>> It could be changed to omit them but given it's a generated editor
>> for the package, one can assume it's always needed and add it
>> explicitly.
>
>
> Makes sense.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 14:16:43 GMT 2024
Powered by FUDForum. Page generated in 0.04674 seconds |
] 
Search
Help
Register
Login
Home
