Home » Modeling » EMF » [CDO] Hierarchical Resources leading to new behaviour?
| [CDO] Hierarchical Resources leading to new behaviour? [message #424241] |
Tue, 21 October 2008 14:48  |
 Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hej Eike,
hi Simon and whoever reads this ;-)
I jsut updated to HEAD and got an unexpected side-effect, which I
suspect the resourceFolders to be responsive for.
In my project I don't use the CDO editor framework, but custom EMF-Edit
based viewers.
This works (well - did work until today) as follows:
public class MyUIPlugin extends AbstractUIPlugin {
private ComposedAdapterFactory adapterFactory;
private AdapterFactoryEditingDomain editingDomain;
private CDOView view;
//...
public void start(BundleContext context) throws Exception {
// ...
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
BasicCommandStack commandStack = new BasicCommandStack();
view = SomeOtherPlugin.getDefault().getSession().openView();
// add resource to view's resource set
view.getResource("/projectxyz/projects");
editingDomain = new AdapterFactoryEditingDomain(adapterFactory, commandStack,
view.getResourceSet());
}
}
//------------------------------------
public class ProjectViewPart extends ViewPart {
private TableViewer tableViewer;
public void createPartControl(Composite parent) {
//...
tableViewer = new TableViewer(parent, SWT.BORDER);
ComposedAdapterFactory adapterFactory = MyUIPlugin.getDefault().getAdapterFactory();
Resource resource = MyUIPlugin.getDefault().getResource();
tableViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory));
tableViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
tableViewer.setInput(resource);
//...
}
}
As stated above, this actually did work until today with the view
showing the first-level contents of the resource.
Now the view is just empty. In the debugger, I find that the cause is
not the resource itself.
((Resource)tableViewer.getInput()).getContents().size() returns 2 (there
are two items in the resource, which is correct).
So it must have something to do with the AdapterFactory. Is the
ResourceItemProviderAdapterFactory not suitable anymore for the new CDO
Resource architecture? I also tried
org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead ->
same result ...
Or is this just an unwanted side-effect of the new implementation (read:
bug) ?!
Thanks in advance,
Cheers,
Stefan
|
|
|
| Re: [CDO] Hierarchical Resources leading to new behaviour? [message #424246 is a reply to message #424241] |
Tue, 21 October 2008 16:04  |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Stefan,
I don't know how complex your MyModelAdapterFactory() is, and I'm not
sure what CDO has changed to not be able to find a proper factory for a
CDOResource. However you could try to add the
EresourceItemProviderAdapterFactory to your ComposedAdapterFactory ;)
....
adapterFactory = new
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFacotyr.addAdapterFactory(new EresourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
....
The code above should work for you...
note: a depedency to org.eclipse.emf.cdo.edit will be required in your
plugin ;).
I hope it helps.
Cheers,
Adolfo.
Stefan Winkler escribió:
> Hej Eike,
> hi Simon and whoever reads this ;-)
>
> I jsut updated to HEAD and got an unexpected side-effect, which I
> suspect the resourceFolders to be responsive for.
>
> In my project I don't use the CDO editor framework, but custom EMF-Edit
> based viewers.
>
> This works (well - did work until today) as follows:
>
> public class MyUIPlugin extends AbstractUIPlugin {
> private ComposedAdapterFactory adapterFactory;
> private AdapterFactoryEditingDomain editingDomain;
> private CDOView view;
> //...
>
> public void start(BundleContext context) throws Exception {
> // ...
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
> adapterFactory.addAdapterFactory(new
> ResourceItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>
> BasicCommandStack commandStack = new BasicCommandStack();
>
> view = SomeOtherPlugin.getDefault().getSession().openView();
>
> // add resource to view's resource set
> view.getResource("/projectxyz/projects");
>
> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
> commandStack, view.getResourceSet());
> }
> }
>
> //------------------------------------
>
> public class ProjectViewPart extends ViewPart {
> private TableViewer tableViewer;
>
> public void createPartControl(Composite parent) {
> //...
> tableViewer = new TableViewer(parent, SWT.BORDER);
> ComposedAdapterFactory adapterFactory =
> MyUIPlugin.getDefault().getAdapterFactory();
> Resource resource = MyUIPlugin.getDefault().getResource();
>
> tableViewer.setContentProvider(new
> AdapterFactoryContentProvider(adapterFactory));
> tableViewer.setLabelProvider(new
> AdapterFactoryLabelProvider(adapterFactory));
> tableViewer.setInput(resource);
> //...
> }
> }
>
> As stated above, this actually did work until today with the view
> showing the first-level contents of the resource.
> Now the view is just empty. In the debugger, I find that the cause is
> not the resource itself.
> ((Resource)tableViewer.getInput()).getContents().size() returns 2 (there
> are two items in the resource, which is correct).
> So it must have something to do with the AdapterFactory. Is the
> ResourceItemProviderAdapterFactory not suitable anymore for the new CDO
> Resource architecture? I also tried
> org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead ->
> same result ...
>
> Or is this just an unwanted side-effect of the new implementation (read:
> bug) ?!
>
> Thanks in advance,
> Cheers,
> Stefan
>
|
|
|
| Re: [CDO] Hierarchical Resources leading to new behaviour? [message #424250 is a reply to message #424246] |
Tue, 21 October 2008 16:23 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Simon
I think that I have discovered the problem...
Having a little insight on code, it seems that the extension point for
the itemProviderAdapterFactory has not been properly updated (the uri
attribute).
I'll raise a bugzilla...
Cheers,
Adolfo.
Adolfo Sánchez-Barbudo Herrera escribió:
> Hi Stefan,
>
> I don't know how complex your MyModelAdapterFactory() is, and I'm not
> sure what CDO has changed to not be able to find a proper factory for a
> CDOResource. However you could try to add the
> EresourceItemProviderAdapterFactory to your ComposedAdapterFactory ;)
>
> ...
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
> adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
> adapterFacotyr.addAdapterFactory(new
> EresourceItemProviderAdapterFactory());
> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
> ...
>
> The code above should work for you...
>
> note: a depedency to org.eclipse.emf.cdo.edit will be required in your
> plugin ;).
>
> I hope it helps.
>
> Cheers,
> Adolfo.
>
> Stefan Winkler escribió:
>> Hej Eike,
>> hi Simon and whoever reads this ;-)
>>
>> I jsut updated to HEAD and got an unexpected side-effect, which I
>> suspect the resourceFolders to be responsive for.
>>
>> In my project I don't use the CDO editor framework, but custom
>> EMF-Edit based viewers.
>>
>> This works (well - did work until today) as follows:
>>
>> public class MyUIPlugin extends AbstractUIPlugin {
>> private ComposedAdapterFactory adapterFactory;
>> private AdapterFactoryEditingDomain editingDomain;
>> private CDOView view;
>> //...
>>
>> public void start(BundleContext context) throws Exception {
>> // ...
>> adapterFactory = new
>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>
>> adapterFactory.addAdapterFactory(new
>> ResourceItemProviderAdapterFactory());
>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>> BasicCommandStack commandStack = new
>> BasicCommandStack();
>>
>> view = SomeOtherPlugin.getDefault().getSession().openView();
>>
>> // add resource to view's resource set
>> view.getResource("/projectxyz/projects");
>> editingDomain = new
>> AdapterFactoryEditingDomain(adapterFactory,
>> commandStack, view.getResourceSet()); }
>> }
>>
>> //------------------------------------
>>
>> public class ProjectViewPart extends ViewPart {
>> private TableViewer tableViewer;
>> public void createPartControl(Composite parent) {
>> //...
>> tableViewer = new TableViewer(parent, SWT.BORDER);
>> ComposedAdapterFactory adapterFactory =
>> MyUIPlugin.getDefault().getAdapterFactory();
>> Resource resource = MyUIPlugin.getDefault().getResource();
>> tableViewer.setContentProvider(new
>> AdapterFactoryContentProvider(adapterFactory));
>> tableViewer.setLabelProvider(new
>> AdapterFactoryLabelProvider(adapterFactory));
>> tableViewer.setInput(resource);
>> //...
>> }
>> }
>>
>> As stated above, this actually did work until today with the view
>> showing the first-level contents of the resource.
>> Now the view is just empty. In the debugger, I find that the cause is
>> not the resource itself.
>> ((Resource)tableViewer.getInput()).getContents().size() returns 2
>> (there are two items in the resource, which is correct).
>> So it must have something to do with the AdapterFactory. Is the
>> ResourceItemProviderAdapterFactory not suitable anymore for the new
>> CDO Resource architecture? I also tried
>> org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead ->
>> same result ...
>>
>> Or is this just an unwanted side-effect of the new implementation
>> (read: bug) ?!
>>
>> Thanks in advance,
>> Cheers,
>> Stefan
>>
|
|
|
| Re: [CDO] Hierarchical Resources leading to new behaviour? [message #424252 is a reply to message #424250] |
Tue, 21 October 2008 16:41 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi guys,
Actually, the org.eclipse.emf.cdo extension points aren't updated neither.
Stefan, applying the attached patch from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251562
should make your views to work again ;).
Cheers,
Adolfo.
Adolfo Sánchez-Barbudo Herrera escribió:
> Hi Simon
>
> I think that I have discovered the problem...
>
> Having a little insight on code, it seems that the extension point for
> the itemProviderAdapterFactory has not been properly updated (the uri
> attribute).
>
> I'll raise a bugzilla...
>
> Cheers,
> Adolfo.
>
> Adolfo Sánchez-Barbudo Herrera escribió:
>> Hi Stefan,
>>
>> I don't know how complex your MyModelAdapterFactory() is, and I'm not
>> sure what CDO has changed to not be able to find a proper factory for
>> a CDOResource. However you could try to add the
>> EresourceItemProviderAdapterFactory to your ComposedAdapterFactory ;)
>>
>> ...
>> adapterFactory = new
>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>
>> adapterFactory.addAdapterFactory(new
>> ResourceItemProviderAdapterFactory());
>> adapterFacotyr.addAdapterFactory(new
>> EresourceItemProviderAdapterFactory());
>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>> ...
>>
>> The code above should work for you...
>>
>> note: a depedency to org.eclipse.emf.cdo.edit will be required in your
>> plugin ;).
>>
>> I hope it helps.
>>
>> Cheers,
>> Adolfo.
>>
>> Stefan Winkler escribió:
>>> Hej Eike,
>>> hi Simon and whoever reads this ;-)
>>>
>>> I jsut updated to HEAD and got an unexpected side-effect, which I
>>> suspect the resourceFolders to be responsive for.
>>>
>>> In my project I don't use the CDO editor framework, but custom
>>> EMF-Edit based viewers.
>>>
>>> This works (well - did work until today) as follows:
>>>
>>> public class MyUIPlugin extends AbstractUIPlugin {
>>> private ComposedAdapterFactory adapterFactory;
>>> private AdapterFactoryEditingDomain editingDomain;
>>> private CDOView view;
>>> //...
>>>
>>> public void start(BundleContext context) throws Exception {
>>> // ...
>>> adapterFactory = new
>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>
>>> adapterFactory.addAdapterFactory(new
>>> ResourceItemProviderAdapterFactory());
>>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>>> BasicCommandStack commandStack = new
>>> BasicCommandStack();
>>>
>>> view = SomeOtherPlugin.getDefault().getSession().openView();
>>>
>>> // add resource to view's resource set
>>> view.getResource("/projectxyz/projects");
>>> editingDomain = new
>>> AdapterFactoryEditingDomain(adapterFactory,
>>> commandStack, view.getResourceSet()); }
>>> }
>>>
>>> //------------------------------------
>>>
>>> public class ProjectViewPart extends ViewPart {
>>> private TableViewer tableViewer;
>>> public void createPartControl(Composite parent) {
>>> //...
>>> tableViewer = new TableViewer(parent, SWT.BORDER);
>>> ComposedAdapterFactory adapterFactory =
>>> MyUIPlugin.getDefault().getAdapterFactory();
>>> Resource resource = MyUIPlugin.getDefault().getResource();
>>> tableViewer.setContentProvider(new
>>> AdapterFactoryContentProvider(adapterFactory));
>>> tableViewer.setLabelProvider(new
>>> AdapterFactoryLabelProvider(adapterFactory));
>>> tableViewer.setInput(resource);
>>> //...
>>> }
>>> }
>>>
>>> As stated above, this actually did work until today with the view
>>> showing the first-level contents of the resource.
>>> Now the view is just empty. In the debugger, I find that the cause is
>>> not the resource itself.
>>> ((Resource)tableViewer.getInput()).getContents().size() returns 2
>>> (there are two items in the resource, which is correct).
>>> So it must have something to do with the AdapterFactory. Is the
>>> ResourceItemProviderAdapterFactory not suitable anymore for the new
>>> CDO Resource architecture? I also tried
>>> org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead ->
>>> same result ...
>>>
>>> Or is this just an unwanted side-effect of the new implementation
>>> (read: bug) ?!
>>>
>>> Thanks in advance,
>>> Cheers,
>>> Stefan
>>>
|
|
|
| Re: [CDO] Hierarchical Resources leading to new behaviour? [message #424263 is a reply to message #424252] |
Tue, 21 October 2008 17:55 |
|
Cool guys, that you're helping each other!!!
My first thought was also htat we missed a place when we increased the
version number within the nsURI of the Eresource package...
Stefan, please confirm if that solves your problem or if we have to
investigate it further...
Cheers
/Eike
Adolfo Sánchez-Barbudo Herrera schrieb:
> Hi guys,
>
> Actually, the org.eclipse.emf.cdo extension points aren't updated
> neither.
>
> Stefan, applying the attached patch from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251562
> should make your views to work again ;).
>
> Cheers,
> Adolfo.
>
> Adolfo Sánchez-Barbudo Herrera escribió:
>> Hi Simon
>>
>> I think that I have discovered the problem...
>>
>> Having a little insight on code, it seems that the extension point
>> for the itemProviderAdapterFactory has not been properly updated (the
>> uri attribute).
>>
>> I'll raise a bugzilla...
>>
>> Cheers,
>> Adolfo.
>>
>> Adolfo Sánchez-Barbudo Herrera escribió:
>>> Hi Stefan,
>>>
>>> I don't know how complex your MyModelAdapterFactory() is, and I'm
>>> not sure what CDO has changed to not be able to find a proper
>>> factory for a CDOResource. However you could try to add the
>>> EresourceItemProviderAdapterFactory to your ComposedAdapterFactory ;)
>>>
>>> ...
>>> adapterFactory = new
>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>
>>> adapterFactory.addAdapterFactory(new
>>> ResourceItemProviderAdapterFactory());
>>> adapterFacotyr.addAdapterFactory(new
>>> EresourceItemProviderAdapterFactory());
>>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>>> ...
>>>
>>> The code above should work for you...
>>>
>>> note: a depedency to org.eclipse.emf.cdo.edit will be required in
>>> your plugin ;).
>>>
>>> I hope it helps.
>>>
>>> Cheers,
>>> Adolfo.
>>>
>>> Stefan Winkler escribió:
>>>> Hej Eike,
>>>> hi Simon and whoever reads this ;-)
>>>>
>>>> I jsut updated to HEAD and got an unexpected side-effect, which I
>>>> suspect the resourceFolders to be responsive for.
>>>>
>>>> In my project I don't use the CDO editor framework, but custom
>>>> EMF-Edit based viewers.
>>>>
>>>> This works (well - did work until today) as follows:
>>>>
>>>> public class MyUIPlugin extends AbstractUIPlugin {
>>>> private ComposedAdapterFactory adapterFactory;
>>>> private AdapterFactoryEditingDomain editingDomain;
>>>> private CDOView view;
>>>> //...
>>>>
>>>> public void start(BundleContext context) throws Exception {
>>>> // ...
>>>> adapterFactory = new
>>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>>
>>>> adapterFactory.addAdapterFactory(new
>>>> ResourceItemProviderAdapterFactory());
>>>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>>>> BasicCommandStack commandStack = new
>>>> BasicCommandStack();
>>>>
>>>> view = SomeOtherPlugin.getDefault().getSession().openView();
>>>>
>>>> // add resource to view's resource set
>>>> view.getResource("/projectxyz/projects");
>>>> editingDomain = new
>>>> AdapterFactoryEditingDomain(adapterFactory,
>>>> commandStack, view.getResourceSet()); }
>>>> }
>>>>
>>>> //------------------------------------
>>>>
>>>> public class ProjectViewPart extends ViewPart {
>>>> private TableViewer tableViewer;
>>>> public void createPartControl(Composite parent) {
>>>> //...
>>>> tableViewer = new TableViewer(parent, SWT.BORDER);
>>>> ComposedAdapterFactory adapterFactory =
>>>> MyUIPlugin.getDefault().getAdapterFactory();
>>>> Resource resource = MyUIPlugin.getDefault().getResource();
>>>> tableViewer.setContentProvider(new
>>>> AdapterFactoryContentProvider(adapterFactory));
>>>> tableViewer.setLabelProvider(new
>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>> tableViewer.setInput(resource);
>>>> //...
>>>> }
>>>> }
>>>>
>>>> As stated above, this actually did work until today with the view
>>>> showing the first-level contents of the resource.
>>>> Now the view is just empty. In the debugger, I find that the cause
>>>> is not the resource itself.
>>>> ((Resource)tableViewer.getInput()).getContents().size() returns 2
>>>> (there are two items in the resource, which is correct).
>>>> So it must have something to do with the AdapterFactory. Is the
>>>> ResourceItemProviderAdapterFactory not suitable anymore for the new
>>>> CDO Resource architecture? I also tried
>>>> org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead
>>>> -> same result ...
>>>>
>>>> Or is this just an unwanted side-effect of the new implementation
>>>> (read: bug) ?!
>>>>
>>>> Thanks in advance,
>>>> Cheers,
>>>> Stefan
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Hierarchical Resources leading to new behaviour? [message #424284 is a reply to message #424263] |
Wed, 22 October 2008 09:31 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi,
See bugzilla. That was indeed the problem.
Thanks for your rapid help, Adolfo!
Cheers,
Stefan
Eike Stepper schrieb:
> Cool guys, that you're helping each other!!!
> My first thought was also htat we missed a place when we increased the
> version number within the nsURI of the Eresource package...
>
> Stefan, please confirm if that solves your problem or if we have to
> investigate it further...
>
> Cheers
> /Eike
>
>
>
> Adolfo Sánchez-Barbudo Herrera schrieb:
>> Hi guys,
>>
>> Actually, the org.eclipse.emf.cdo extension points aren't updated
>> neither.
>>
>> Stefan, applying the attached patch from
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251562
>> should make your views to work again ;).
>>
>> Cheers,
>> Adolfo.
>>
>> Adolfo Sánchez-Barbudo Herrera escribió:
>>> Hi Simon
>>>
>>> I think that I have discovered the problem...
>>>
>>> Having a little insight on code, it seems that the extension point
>>> for the itemProviderAdapterFactory has not been properly updated
>>> (the uri attribute).
>>>
>>> I'll raise a bugzilla...
>>>
>>> Cheers,
>>> Adolfo.
>>>
>>> Adolfo Sánchez-Barbudo Herrera escribió:
>>>> Hi Stefan,
>>>>
>>>> I don't know how complex your MyModelAdapterFactory() is, and I'm
>>>> not sure what CDO has changed to not be able to find a proper
>>>> factory for a CDOResource. However you could try to add the
>>>> EresourceItemProviderAdapterFactory to your ComposedAdapterFactory ;)
>>>>
>>>> ...
>>>> adapterFactory = new
>>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>>
>>>> adapterFactory.addAdapterFactory(new
>>>> ResourceItemProviderAdapterFactory());
>>>> adapterFacotyr.addAdapterFactory(new
>>>> EresourceItemProviderAdapterFactory());
>>>> adapterFactory.addAdapterFactory(new MyModelAdapterFactory());
>>>> ...
>>>>
>>>> The code above should work for you...
>>>>
>>>> note: a depedency to org.eclipse.emf.cdo.edit will be required in
>>>> your plugin ;).
>>>>
>>>> I hope it helps.
>>>>
>>>> Cheers,
>>>> Adolfo.
>>>>
>>>> Stefan Winkler escribió:
>>>>> Hej Eike,
>>>>> hi Simon and whoever reads this ;-)
>>>>>
>>>>> I jsut updated to HEAD and got an unexpected side-effect, which I
>>>>> suspect the resourceFolders to be responsive for.
>>>>>
>>>>> In my project I don't use the CDO editor framework, but custom
>>>>> EMF-Edit based viewers.
>>>>>
>>>>> This works (well - did work until today) as follows:
>>>>>
>>>>> public class MyUIPlugin extends AbstractUIPlugin {
>>>>> private ComposedAdapterFactory adapterFactory;
>>>>> private AdapterFactoryEditingDomain editingDomain;
>>>>> private CDOView view;
>>>>> //...
>>>>>
>>>>> public void start(BundleContext context) throws Exception {
>>>>> // ...
>>>>> adapterFactory = new
>>>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>>>>
>>>>> adapterFactory.addAdapterFactory(new
>>>>> ResourceItemProviderAdapterFactory());
>>>>> adapterFactory.addAdapterFactory(new
>>>>> MyModelAdapterFactory());
>>>>> BasicCommandStack commandStack = new
>>>>> BasicCommandStack();
>>>>>
>>>>> view = SomeOtherPlugin.getDefault().getSession().openView();
>>>>>
>>>>> // add resource to view's resource set
>>>>> view.getResource("/projectxyz/projects");
>>>>> editingDomain = new
>>>>> AdapterFactoryEditingDomain(adapterFactory,
>>>>> commandStack, view.getResourceSet()); }
>>>>> }
>>>>>
>>>>> //------------------------------------
>>>>>
>>>>> public class ProjectViewPart extends ViewPart {
>>>>> private TableViewer tableViewer;
>>>>> public void createPartControl(Composite parent) {
>>>>> //...
>>>>> tableViewer = new TableViewer(parent, SWT.BORDER);
>>>>> ComposedAdapterFactory adapterFactory =
>>>>> MyUIPlugin.getDefault().getAdapterFactory();
>>>>> Resource resource = MyUIPlugin.getDefault().getResource();
>>>>> tableViewer.setContentProvider(new
>>>>> AdapterFactoryContentProvider(adapterFactory));
>>>>> tableViewer.setLabelProvider(new
>>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>>> tableViewer.setInput(resource);
>>>>> //...
>>>>> }
>>>>> }
>>>>>
>>>>> As stated above, this actually did work until today with the view
>>>>> showing the first-level contents of the resource.
>>>>> Now the view is just empty. In the debugger, I find that the cause
>>>>> is not the resource itself.
>>>>> ((Resource)tableViewer.getInput()).getContents().size() returns 2
>>>>> (there are two items in the resource, which is correct).
>>>>> So it must have something to do with the AdapterFactory. Is the
>>>>> ResourceItemProviderAdapterFactory not suitable anymore for the
>>>>> new CDO Resource architecture? I also tried
>>>>> org.eclipse.emf.cdo.eresource.util.EresourceAdapterFactory instead
>>>>> -> same result ...
>>>>>
>>>>> Or is this just an unwanted side-effect of the new implementation
>>>>> (read: bug) ?!
>>>>>
>>>>> Thanks in advance,
>>>>> Cheers,
>>>>> Stefan
>>>>>
|
|
|
Goto Forum:
Current Time: Thu Sep 19 04:51:27 GMT 2024
Powered by FUDForum. Page generated in 0.03443 seconds |
] 
Search
Help
Register
Login
Home
