|
| Re: dedicated or shared resource sets [message #424542 is a reply to message #424541] |
Wed, 29 October 2008 19:26   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Knut,
Comments below.
Knut Wannheden wrote:
> Hi,
>
> I am looking for some advice on the usage of resource sets when
> support for multiple simultaneously open editors (for separate but
> related resources) is required. In many ways I want to support
> something similar to the JDT Java editor where I in the editor for one
> Java class Foo can reference declarations of another class Bar as it's
> defined in another open editor, even when the referenced declaration
> has not yet been saved by the editor (it's dirty).
It's rather nice.
>
> Basically I can see two distinct approaches for managing the edited
> resources:
>
> 1. Each editor instance has its own dedicated resource set only
> containing the resource being edited. To avoid having to load related
> resources into multiple resource sets (of the corresponding editors)
> the object references would span resource set boundaries, which AFAICT
> is not forbidden in EMF.
No, but it starts to get tricky...
> To support proxy resolution of such references (without loading the
> referenced resource into the same resource set) I would create my own
> resource set implementation overriding delegatedGetResource to return
> a resource from another resource set. I found this "trick" being
> mentioned in the following post:
> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg1 4938.html.
We provide lots of hooks to do all kinds of things...
>
> 2. All open editors share a single resource set (default EMF
> implementation).
Each has their own separate one.
> References don't need to cross resource set boundaries and therefore
> no special action is required for proxy resolution.
Each is loaded locally. Sharing only happens via saves to the
workspace, which are then loaded elsewhere via resource delta monitoring.
Very simple, but if you change things in two places, not so nice.
>
> Do both of these approaches make sense? When would I use one or the
> other?
It's really complexity and the user experience.
> What implications should be considered?
How hard is it to get right! :-P
> In case it makes a difference: I probably won't use the EMF.Edit layer.
It's a complex problem that's worse than the JDT case with source files
because models can be intimated inter-related. Changing one can make
changes in the other. So undo stacks become intertwined. The
transaction APIs can help with this. Probably it's worth reading about
them...
>
> Regards,
>
> --knut
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: dedicated or shared resource sets [message #424544 is a reply to message #424542] |
Wed, 29 October 2008 19:40 |
Knut Wannheden
Messages: 298
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks for your quick reply.
I should probably have mentioned that I'm not talking about the standard
EMF.Editor generated for me. I'm actually intending to use a oAW Xtext
editors, which as I mentioned also don't use EMF.Edit. With those editors
I would have the option to use a single shared resource set. But I wonder
if that's good or not.
I will take a look at the Transaction API, but I thought that was based on
EMF.Edit.
Regards,
--knut
Ed Merks wrote:
> Knut,
> Comments below.
> Knut Wannheden wrote:
>> Hi,
>>
>> I am looking for some advice on the usage of resource sets when
>> support for multiple simultaneously open editors (for separate but
>> related resources) is required. In many ways I want to support
>> something similar to the JDT Java editor where I in the editor for one
>> Java class Foo can reference declarations of another class Bar as it's
>> defined in another open editor, even when the referenced declaration
>> has not yet been saved by the editor (it's dirty).
> It's rather nice.
>>
>> Basically I can see two distinct approaches for managing the edited
>> resources:
>>
>> 1. Each editor instance has its own dedicated resource set only
>> containing the resource being edited. To avoid having to load related
>> resources into multiple resource sets (of the corresponding editors)
>> the object references would span resource set boundaries, which AFAICT
>> is not forbidden in EMF.
> No, but it starts to get tricky...
>> To support proxy resolution of such references (without loading the
>> referenced resource into the same resource set) I would create my own
>> resource set implementation overriding delegatedGetResource to return
>> a resource from another resource set. I found this "trick" being
>> mentioned in the following post:
>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg1 4938.html.
> We provide lots of hooks to do all kinds of things...
>>
>> 2. All open editors share a single resource set (default EMF
>> implementation).
> Each has their own separate one.
>> References don't need to cross resource set boundaries and therefore
>> no special action is required for proxy resolution.
> Each is loaded locally. Sharing only happens via saves to the
> workspace, which are then loaded elsewhere via resource delta monitoring.
> Very simple, but if you change things in two places, not so nice.
>>
>> Do both of these approaches make sense? When would I use one or the
>> other?
> It's really complexity and the user experience.
>> What implications should be considered?
> How hard is it to get right! :-P
>> In case it makes a difference: I probably won't use the EMF.Edit layer.
> It's a complex problem that's worse than the JDT case with source files
> because models can be intimated inter-related. Changing one can make
> changes in the other. So undo stacks become intertwined. The
> transaction APIs can help with this. Probably it's worth reading about
> them...
>>
>> Regards,
>>
>> --knut
>>
Hi
|
|
|
Powered by
FUDForum. Page generated in 0.03358 seconds
] 
Search
Help
Register
Login
Home
