Home » Modeling » EMF » Model editing, best practices
| Model editing, best practices [message #850042] |
Thu, 19 April 2012 17:56  |
 Cedric Moonen
Messages: 274
Registered: August 2009 |
Senior Member |
|
|
Hello,
Suppose that my ecore domain model defines "EventType" which contains properties (defined by a name and a type and maybe some additional properties which are not relevant). Each event type can also reference other event types being its super types (an event type can inherit from other event types).
Each event type is saved in its own resource (so one event type per file). The location of the file on the file system is relevant: it defines some kind of package similar as what we have in Java. The event type also has an ID which is his package and its name (similar as a fully qualified name in java). So, it means that if we want to modify the ID of event, the resource also has to be moved on the file system.
My application uses these event types (they are referenced from non EMF objects). Through the application, I will provide some editing support to edit those event types and several questions arise:
1) How can I implement a system that allows me to change the ID of an event type so that when it is saved, the resource will be moved to the correct directory ? I was thinking of something like creating my own ResourceSet which will only load event type resources. It can then observe the event types and if an ID changes, it will delete the original resource, create a new resource and save the event type to the new resource (at the correct location).
2) Another problem occurs in that case: all event types which are referencing the moved event type have to be saved again. Indeed, they are still valid in memory but the persisted file will still contain a reference to the original file.
There's maybe a solution here by using the CrossReferencer class to retrieve all objects that are referencing the modified event type and then for all of these force a save again.
3) This could maybe work but then another problem arise: if these event types (the ones which were referencing the modified event type) are dirty (because they are also being edited), then those modifications will be persisted to the file at the same time, which is undersired behaviour.
4) When editing an event type, I could first clone it and edit the clone but this leads to other problems when the event type is set back (references are broken and so on).
I was wondering if you have some suggestions here about a possible solution. I'm merely looking at some possibilities here, since I don't know all the power of what EMF can do.
Thanks for any tips or suggestion.
Cédric
|
|
|
| Re: Model editing, best practices [message #850517 is a reply to message #850042] |
Fri, 20 April 2012 05:13  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cedric,
Comments below.
On 19/04/2012 7:56 PM, Cedric Moonen wrote:
> Hello,
>
> Suppose that my ecore domain model defines "EventType" which contains
> properties (defined by a name and a type and maybe some additional
> properties which are not relevant). Each event type can also reference
> other event types being its super types (an event type can inherit
> from other event types).
> Each event type is saved in its own resource (so one event type per
> file). The location of the file on the file system is relevant: it
> defines some kind of package similar as what we have in Java. The
> event type also has an ID which is his package and its name (similar
> as a fully qualified name in java). So, it means that if we want to
> modify the ID of event, the resource also has to be moved on the file
> system.
So the location in the file system isn't entirely irrelevant given that
the name of the even has to match the name (last segment of the URI) of
the resource.
>
> My application uses these event types (they are referenced from non
> EMF objects). Through the application, I will provide some editing
> support to edit those event types and several questions arise:
>
> 1) How can I implement a system that allows me to change the ID of an
> event type so that when it is saved, the resource will be moved to the
> correct directory ?
You'll need to manage the resource's URI...
> I was thinking of something like creating my own ResourceSet which
> will only load event type resources. It can then observe the event
> types and if an ID changes, it will delete the original resource,
> create a new resource and save the event type to the new resource (at
> the correct location).
At what point would you do this? If you're talking about an editor,
they generally affect the state of the file system (workspace) only when
you save, and not on each change you make in the editor.
> 2) Another problem occurs in that case: all event types which are
> referencing the moved event type have to be saved again.
So they'd all need to be loaded. It's kind of more of a refactoring
type of problem...
> Indeed, they are still valid in memory but the persisted file will
> still contain a reference to the original file. There's maybe a
> solution here by using the CrossReferencer class to retrieve all
> objects that are referencing the modified event type and then for all
> of these force a save again.
The generated editor tries to save all resources in the resource set and
use the SAVE_ONLY_IF_CHANGED option so that if what they're going to
save is byte-for-byte equal to what's already there in the file system
is the same, they discard the change and hence avoid increasing the
timestamp in the file system unnecessarily.
> 3) This could maybe work but then another problem arise: if these
> event types (the ones which were referencing the modified event type)
> are dirty (because they are also being edited), then those
> modifications will be persisted to the file at the same time, which is
> undersired behaviour.
That's why I characterized this as more of a refactoring type of
change. Often refactoring tools encourage you to save all your dirty
editors before you do the refactoring.
> 4) When editing an event type, I could first clone it and edit the
> clone but this leads to other problems when the event type is set back
> (references are broken and so on).
>
> I was wondering if you have some suggestions here about a possible
> solution. I'm merely looking at some possibilities here, since I don't
> know all the power of what EMF can do.
The Xtext project has pretty nice refactoring support and has been used
to define languages like Xtend, which, like Java, require that the name
of the Xtend class matches the name of the file, as well as having the
notition of packages, which imply correspondingly-named nested folders.
Your event language sounds like it would benefit significantly from a
human readable textual serialization. The added benefit of that
approach is that locating resource is done via the qualified identifier
name (what you're calling the ID of the event) in conjunction with the
normal Java classpath (you can see any Event whose resource is visible
on the classpath). It also supports indexing, so you'll know all the
resources in your workspace that reference a particular Event).
>
> Thanks for any tips or suggestion.
> Cédric
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Model editing, best practices [message #850616 is a reply to message #850517] |
Fri, 20 April 2012 07:13 |
Cedric Moonen
Messages: 274
Registered: August 2009 |
Senior Member |
|
|
Ed,
Thanks for the reply. Comments are below.
Quote:So the location in the file system isn't entirely irrelevant given that
the name of the even has to match the name (last segment of the URI) of
the resource.
Yes, that is what I said. It's event more complex than that since the ID of the event type has to match the location on the resource, not only the name.
Quote:> I was thinking of something like creating my own ResourceSet which
> will only load event type resources. It can then observe the event
> types and if an ID changes, it will delete the original resource,
> create a new resource and save the event type to the new resource (at
> the correct location).
At what point would you do this? If you're talking about an editor,
they generally affect the state of the file system (workspace) only when
you save, and not on each change you make in the editor.
Yes indeed, and this is not what I would like to have. It should indeed only modify the resource location on save.
Quote:So they'd all need to be loaded. It's kind of more of a refactoring
type of problem...
Indeed, this is a refactoring issue but with an additional feature: if the property being edited is the event type ID, then the resource has to be relocated when you save the event type.
Quote:The Xtext project has pretty nice refactoring support and has been used
to define languages like Xtend, which, like Java, require that the name
of the Xtend class matches the name of the file, as well as having the
notition of packages, which imply correspondingly-named nested folders.
Your event language sounds like it would benefit significantly from a
human readable textual serialization. The added benefit of that
approach is that locating resource is done via the qualified identifier
name (what you're calling the ID of the event) in conjunction with the
normal Java classpath (you can see any Event whose resource is visible
on the classpath). It also supports indexing, so you'll know all the
resources in your workspace that reference a particular Event).
Yes, we know xtext and we have been using it in previous projects too and we were wondering if it could be used to solve a part of our problems. Unfortunately, there are some other problems which arise here too:
1) We have two usage scenarios for our application: it can be run as an RCP application or as a standalone console application. In both cases, it runs outside a standard Eclipse installation, which means that (as far as I know) we don't have support for the Xtext indexer. So, we loose all the power of refactoring here.
2) Those event types are referenced by other model elements for which we don't want to provide an xtext editor (we want to provide our own form based editor). But the refactoring support has still to work for those elements. I guess this could be solved by providing an Xtext editor anyway but not use it (only for the purpose of Xtext indexing the files).
Anyway, I think Xtext will probably be one of the best option here, and that we should be able to tweek it in order to reach what we want to achieve.
Thanks,
Cédric
|
|
|
| Re: Model editing, best practices [message #850823 is a reply to message #850616] |
Fri, 20 April 2012 11:10 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cedric,
Comments below.
On 20/04/2012 9:13 AM, Cedric Moonen wrote:
> Ed,
>
> Thanks for the reply. Comments are below.
>
> Quote:
>> So the location in the file system isn't entirely irrelevant given
>> that the name of the even has to match the name (last segment of the
>> URI) of the resource.
>
>
> Yes, that is what I said. It's event more complex than that since the
> ID of the event type has to match the location on the resource, not
> only the name.
>
> Quote:
>> > I was thinking of something like creating my own ResourceSet which
>> > will only load event type resources. It can then observe the event
>> > types and if an ID changes, it will delete the original resource, >
>> create a new resource and save the event type to the new resource (at
>> > the correct location).
>> At what point would you do this? If you're talking about an editor,
>> they generally affect the state of the file system (workspace) only
>> when you save, and not on each change you make in the editor.
>
>
> Yes indeed, and this is not what I would like to have. It should
> indeed only modify the resource location on save.
Yes, and that's quite tricky in that not only do you need to save all
the resources, you'll want to delete the ones that have been renamed/moved.
>
> Quote:
>> So they'd all need to be loaded. It's kind of more of a refactoring
>> type of problem...
>
>
> Indeed, this is a refactoring issue but with an additional feature: if
> the property being edited is the event type ID, then the resource has
> to be relocated when you save the event type.
Think about how Java does this though. You don't just rename the class
by editing the name, you invoke rename refactoring
>
> Quote:
>> The Xtext project has pretty nice refactoring support and has been
>> used to define languages like Xtend, which, like Java, require that
>> the name of the Xtend class matches the name of the file, as well as
>> having the notition of packages, which imply correspondingly-named
>> nested folders. Your event language sounds like it would benefit
>> significantly from a human readable textual serialization. The added
>> benefit of that approach is that locating resource is done via the
>> qualified identifier name (what you're calling the ID of the event)
>> in conjunction with the normal Java classpath (you can see any Event
>> whose resource is visible on the classpath). It also supports
>> indexing, so you'll know all the resources in your workspace that
>> reference a particular Event).
>
>
> Yes, we know xtext and we have been using it in previous projects too
> and we were wondering if it could be used to solve a part of our
> problems. Unfortunately, there are some other problems which arise
> here too:
>
> 1) We have two usage scenarios for our application: it can be run as
> an RCP application or as a standalone console application. In both
> cases, it runs outside a standard Eclipse installation, which means
> that (as far as I know) we don't have support for the Xtext indexer.
I'm not sure about that. Best you ask them on their newsgroup.
> So, we loose all the power of refactoring here.
Refactoring is typically an IDE thing...
> 2) Those event types are referenced by other model elements for which
> we don't want to provide an xtext editor (we want to provide our own
> form based editor). But the refactoring support has still to work for
> those elements. I guess this could be solved by providing an Xtext
> editor anyway but not use it (only for the purpose of Xtext indexing
> the files).
>
> Anyway, I think Xtext will probably be one of the best option here,
> and that we should be able to tweek it in order to reach what we want
> to achieve.
I think so.
> Thanks,
> Cédric
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 09:21:34 GMT 2024
Powered by FUDForum. Page generated in 0.03497 seconds |
] 
Search
Help
Register
Login
Home
