Home » Modeling » EMF » Re: EMF model editing /persistence in a "typical" RCP/IDE app
| Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686685] |
Mon, 09 May 2011 20:16  |
 Dan Pollitt
Messages: 55
Registered: August 2010 |
Member |
|
|
Hi Ed,
Thanks for the pointer - I have read around CDO and had a brief play
with it, definately something that's interesting and on our radar
however I didn't want to jump too soon as it could be quite an
architectural shift - would like to better understand the more
foundational mechanisms first.
Dan
On 09/05/2011 05:52, Ed Willink wrote:
> Hi Dan
>
> I think you should look at CDO which enhances EMF with a rich range of
> persistence options for EObjects in databases.
>
> Regards
>
> Ed Willink
>
> On 09/05/2011 00:01, Dan Pollitt wrote:
>> Hi,
>>
>> I have a few questions relating to how one should (or typically would)
>> approach the usage of EMF persistence mechanisms (ResourceSet,
>> Resource) as well as command based editing mechanisms (EditingDomain)
>> within an Eclipse application where I would like to have specialised
>> editors for certain model elements/sub graphs within a model. Assuming
>> default XMI-based local file/workspace persistence.
>>
>> I'll use the library model example
>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>> I'd like to be able to do:
>>
>> 1. Create a library model instance within a workspace project, a user
>> would think of a workspace project as 1:1 with a Library.
>>
>> 2. Access a library model as part of extensions to the common
>> navigator framework (CNF), to show and react to changes to model
>> structure under a workspace project (as opposed to file system
>> resources) as a tree in the Project Explorer view.
>>
>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>> Book or a Writer, edits should have undo/redo support and saving a
>> dirty Book editor should persist the Book instance.
>>
>>
>> Questions
>> ---------
>>
>> a. As I have read: "a resource is the basic unit of persistence in
>> EMF" - so does that mean that an Eclipse editor needs to operate at
>> the level of a resource? i.e. for a Book editor, I'd need to enable
>> cross-resource containment and make sure Books were created in their
>> own resource?
>>
>> b. Is a ResourceSet an appropriate tool to use to restrict the
>> visibility of changes before persisting them to disk? An example might
>> be: I open an editor for a Book and make some changes. Before saving
>> the editor I can see the effects in the editors copy of the model but
>> nowhere else - after saving other in-memory copies of the model (e.g
>> the content provider for the CNF viewer) can react, presumuably by
>> monitoring the workspace resources?
>>
>> c. I'm imagining that for parts of the application that just need to
>> interrogate/read/observe the model there would be some single place to
>> go to get references into a "golden copy" (i.e. only contain data that
>> has been read from a persistent source) of the model - is that a
>> pattern that people have used and might recommend?
>>
>>
>>
>> I have implementations of an EMF-backed CNF viewer, custom editors
>> (based on code from generated editors) etc - I'm really looking for
>> advice and/or patterns regarding how people have approached the
>> persistence/editing areas - When would you share/create a new
>> ResourceSet/EditingDomain? What are some of the strategies for
>> detecting change conflicts in a resource? For a given model element
>> instance would you only expect to have one in-memory object for it in
>> the VM?
>>
>> I can only hope someone is writing a book that sits on-top of the EMF
>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>
>>
>> Many thanks,
>> Dan
>
|
|
|
| Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686696 is a reply to message #686685] |
Tue, 10 May 2011 07:52  |
|
Am 09.05.2011 22:16, schrieb Dan Pollitt:
> Hi Ed,
>
> Thanks for the pointer - I have read around CDO and had a brief play with it, definately something that's interesting and on our radar however I didn't want to jump too soon as it could be quite an architectural shift
That might definitely be the case but in many cases the influence on the architecture is a good one :P
> - would like to better understand the more foundational mechanisms first.
Your questions are very welcome. Please feel free to ask here.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Dan
>
> On 09/05/2011 05:52, Ed Willink wrote:
>> Hi Dan
>>
>> I think you should look at CDO which enhances EMF with a rich range of
>> persistence options for EObjects in databases.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 09/05/2011 00:01, Dan Pollitt wrote:
>>> Hi,
>>>
>>> I have a few questions relating to how one should (or typically would)
>>> approach the usage of EMF persistence mechanisms (ResourceSet,
>>> Resource) as well as command based editing mechanisms (EditingDomain)
>>> within an Eclipse application where I would like to have specialised
>>> editors for certain model elements/sub graphs within a model. Assuming
>>> default XMI-based local file/workspace persistence.
>>>
>>> I'll use the library model example
>>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>>> I'd like to be able to do:
>>>
>>> 1. Create a library model instance within a workspace project, a user
>>> would think of a workspace project as 1:1 with a Library.
>>>
>>> 2. Access a library model as part of extensions to the common
>>> navigator framework (CNF), to show and react to changes to model
>>> structure under a workspace project (as opposed to file system
>>> resources) as a tree in the Project Explorer view.
>>>
>>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>>> Book or a Writer, edits should have undo/redo support and saving a
>>> dirty Book editor should persist the Book instance.
>>>
>>>
>>> Questions
>>> ---------
>>>
>>> a. As I have read: "a resource is the basic unit of persistence in
>>> EMF" - so does that mean that an Eclipse editor needs to operate at
>>> the level of a resource? i.e. for a Book editor, I'd need to enable
>>> cross-resource containment and make sure Books were created in their
>>> own resource?
>>>
>>> b. Is a ResourceSet an appropriate tool to use to restrict the
>>> visibility of changes before persisting them to disk? An example might
>>> be: I open an editor for a Book and make some changes. Before saving
>>> the editor I can see the effects in the editors copy of the model but
>>> nowhere else - after saving other in-memory copies of the model (e.g
>>> the content provider for the CNF viewer) can react, presumuably by
>>> monitoring the workspace resources?
>>>
>>> c. I'm imagining that for parts of the application that just need to
>>> interrogate/read/observe the model there would be some single place to
>>> go to get references into a "golden copy" (i.e. only contain data that
>>> has been read from a persistent source) of the model - is that a
>>> pattern that people have used and might recommend?
>>>
>>>
>>>
>>> I have implementations of an EMF-backed CNF viewer, custom editors
>>> (based on code from generated editors) etc - I'm really looking for
>>> advice and/or patterns regarding how people have approached the
>>> persistence/editing areas - When would you share/create a new
>>> ResourceSet/EditingDomain? What are some of the strategies for
>>> detecting change conflicts in a resource? For a given model element
>>> instance would you only expect to have one in-memory object for it in
>>> the VM?
>>>
>>> I can only hope someone is writing a book that sits on-top of the EMF
>>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>>
>>>
>>> Many thanks,
>>> Dan
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686852 is a reply to message #686685] |
Tue, 10 May 2011 07:52 |
|
Am 09.05.2011 22:16, schrieb Dan Pollitt:
> Hi Ed,
>
> Thanks for the pointer - I have read around CDO and had a brief play with it, definately something that's interesting and on our radar however I didn't want to jump too soon as it could be quite an architectural shift
That might definitely be the case but in many cases the influence on the architecture is a good one :P
> - would like to better understand the more foundational mechanisms first.
Your questions are very welcome. Please feel free to ask here.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Dan
>
> On 09/05/2011 05:52, Ed Willink wrote:
>> Hi Dan
>>
>> I think you should look at CDO which enhances EMF with a rich range of
>> persistence options for EObjects in databases.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 09/05/2011 00:01, Dan Pollitt wrote:
>>> Hi,
>>>
>>> I have a few questions relating to how one should (or typically would)
>>> approach the usage of EMF persistence mechanisms (ResourceSet,
>>> Resource) as well as command based editing mechanisms (EditingDomain)
>>> within an Eclipse application where I would like to have specialised
>>> editors for certain model elements/sub graphs within a model. Assuming
>>> default XMI-based local file/workspace persistence.
>>>
>>> I'll use the library model example
>>> (http://wiki.eclipse.org/Example_library_EMF_model) to illustrate what
>>> I'd like to be able to do:
>>>
>>> 1. Create a library model instance within a workspace project, a user
>>> would think of a workspace project as 1:1 with a Library.
>>>
>>> 2. Access a library model as part of extensions to the common
>>> navigator framework (CNF), to show and react to changes to model
>>> structure under a workspace project (as opposed to file system
>>> resources) as a tree in the Project Explorer view.
>>>
>>> 3. Open an editor to edit a subset of a library model instance, e.g. a
>>> Book or a Writer, edits should have undo/redo support and saving a
>>> dirty Book editor should persist the Book instance.
>>>
>>>
>>> Questions
>>> ---------
>>>
>>> a. As I have read: "a resource is the basic unit of persistence in
>>> EMF" - so does that mean that an Eclipse editor needs to operate at
>>> the level of a resource? i.e. for a Book editor, I'd need to enable
>>> cross-resource containment and make sure Books were created in their
>>> own resource?
>>>
>>> b. Is a ResourceSet an appropriate tool to use to restrict the
>>> visibility of changes before persisting them to disk? An example might
>>> be: I open an editor for a Book and make some changes. Before saving
>>> the editor I can see the effects in the editors copy of the model but
>>> nowhere else - after saving other in-memory copies of the model (e.g
>>> the content provider for the CNF viewer) can react, presumuably by
>>> monitoring the workspace resources?
>>>
>>> c. I'm imagining that for parts of the application that just need to
>>> interrogate/read/observe the model there would be some single place to
>>> go to get references into a "golden copy" (i.e. only contain data that
>>> has been read from a persistent source) of the model - is that a
>>> pattern that people have used and might recommend?
>>>
>>>
>>>
>>> I have implementations of an EMF-backed CNF viewer, custom editors
>>> (based on code from generated editors) etc - I'm really looking for
>>> advice and/or patterns regarding how people have approached the
>>> persistence/editing areas - When would you share/create a new
>>> ResourceSet/EditingDomain? What are some of the strategies for
>>> detecting change conflicts in a resource? For a given model element
>>> instance would you only expect to have one in-memory object for it in
>>> the VM?
>>>
>>> I can only hope someone is writing a book that sits on-top of the EMF
>>> bible, maybe a "Building Eclipse applications with EMF"... :o)
>>>
>>>
>>> Many thanks,
>>> Dan
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:10:20 GMT 2024
Powered by FUDForum. Page generated in 0.02873 seconds |
] 
Search
Help
Register
Login
Home
