| Re: EMF model editing /persistence in a "typical" RCP/IDE app [message #686686] |
Mon, 09 May 2011 20:35 |
 Dan Pollitt
Messages: 55
Registered: August 2010 |
Member |
|
|
Hi Ed,
Thanks for the information - it's starting to come together. I think
early steps will be to think through how typical edit scenarios will
affect resources as well as deciding which aspects of the system should
reflect the persisted state of resources vs. dirty.
Next on the investigation list is the EMF Model Transaction layer..
Cheers,
Dan
On 09/05/2011 07:07, Ed Merks wrote:
> Guys,
>
> Comments below.
>
> 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.
> CDO is certainly very useful, but I'm not sure anything Dan describes
> calls for it.
>>
>> 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?
> Typically, yes.
>>> i.e. for a Book editor, I'd need to enable cross-resource containment
>>> and make sure Books were created in their own resource?
> Keep in mind that editors are typically dealing with a resource set that
> can contain multiple resources to deal with resources that have
> references to other resources...
>>>
>>> b. Is a ResourceSet an appropriate tool to use to restrict the
>>> visibility of changes before persisting them to disk?
> It's more of a closure of referenced resources starting with the
> primary/initial resource.
>>> 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
> Yes, by default each editor has it's own resource set with a local copy
> of all the resources it's loaded in.
>>> - 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?
> Yes, the default generated editor does that as well, i.e., updates to
> reflect resource deltas.
>>>
>>> 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?
> Typically all the different editors and the navigator either share a
> single copy or maintain their own copy...
>>>
>>>
>>>
>>> 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?
> That's totally up to the behavior you'd like to see. I.e., should the
> CNF immediately reflect changes in the editor even before they're saved?
>>> What are some of the strategies for detecting change conflicts in a
>>> resource?
> Resources to support modification tracking but it's possible that a
> resource's serialization changes not because anything contained in the
> resource is changed but because an object referenced by the resource is
> modified in a way that changes it's URI, i.e. if it's moved to a
> difference resource.
>>> For a given model element instance would you only expect to have one
>>> in-memory object for it in the VM?
> Nothing every expects that, but you could certain try to achieve that
> with a single shared editing domain.
>>>
>>> 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)
> No one is writing another book. There's no significant money to be made
> that way...
>>>
>>>
>>> Many thanks,
>>> Dan
>>
|
|
|
Powered by
FUDForum. Page generated in 0.02491 seconds
] 
Search
Help
Register
Login
Home
