Hello e4-Team,
working on Bug 389624<https://bugs.eclipse.org/bugs/show_bug.cgi?id=389624> I
have stumbled onto another flaw in the current way the framework handles the
persisted model when fragments are used to extend a base application model. I
could invest some time to work on this. Before I start though, I would be happy
about some opinions.
Suppose you start with this simple application model:
- Application (ID: app)
- TrimmedWindow (ID: window)
- PartSashContainer (ID: sash1)
- PartStack (ID: stack1)
- PartStack (ID: stack2)
With some contributions in a fragment:
- StringModelFragment (ID: stack1, feature: children)
- Part (ID: part1)
- StringModelFragment (ID: stack2, feature: children)
- Part (ID: part2)
- Part (ID: part3)
After loading the base model and the fragments, the application model looks
like this:
- Application (ID: app)
- TrimmedWindow (ID: window)
- PartSashContainer (ID: sash1)
- PartStack (ID: stack1)
- Part (ID: part1)
- PartStack (ID: stack2)
- Part (ID: part2)
- Part (ID: part3)
After the application is started the user can drag/drop part3 and drop it in
stack1 next to part1. Closing the application, this will be persisted in
workbench.xmi:
- Application (ID: app)
- TrimmedWindow (ID: window)
- PartSashContainer (ID: sash1)
- PartStack (ID: stack1)
- Part (ID: part1)
- Part (ID: part3)
- PartStack (ID: stack2)
- Part (ID: part2)
So far, so good. The problem arises on the next start of the application.
First, the model from workbench.xmi is loaded (as above). Next, all the
fragments are loaded and the contributions are added/replaced in the model.
Currently, this is achieved by merging the contributions into the parent
defined by the StringModelFragment. Since part3 is contributed to stack2 and
stack2 does not have a child with that id, the part will be added to the list.
The resulting model looks like this:
- Application (ID: app)
- TrimmedWindow (ID: window)
- PartSashContainer (ID: sash1)
- PartStack (ID: stack1)
- Part (ID: part1)
- Part (ID: part3)
- PartStack (ID: stack2)
- Part (ID: part2)
- Part (ID: part3)
This is not what was intended and leads to all sorts of problems.
So the question is how to handle a persisted model. I have the feeling that the
situation is not quite clear when a persisted model (workbench.xmi) is present,
since the original model (Application.e4xmi) is not merged, but fragments are.
One possible solution would be to just not merge the fragments, since the
elements are included in workbench.xmi anyway.
This leads to another question: How does the framework handle model evolution?
I am thinking about this approach:
1) Load the model from workbench.xmi (without additional fragments and
processors)
2) Load the application model and merge all fragments and run all
processors
3) Compare the two models, removing all elements which are not present in
(2) and adding all elements which are present in (1)
This processing could be disabled by a flag (i.e. -checkForModelEvolution).
Any thoughts?
Regards
Christoph
--
Christoph Keimel
EM-SOFTWARE GmbH
Oskar-Messter-Str. 29
85737 Ismaning
Tel.: 089-99 65 47-26 Fax.: 089-99 65 47-99
Web: www.emsw.de<http://www.emsw.de/> E-Mail:
[email protected]<mailto:[email protected]>
Geschäftsführer: Dipl.-Inf. (FH) Georg Engl
UST-Id-Nr.: DE 131 175 644, HRB 80271 München
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
