@Christoph, do you see a relation to https://bugs.eclipse.org/bugs/show_bug.cgi?id=382184
Best regards, Kai > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Tom Schindl > Sent: Sonntag, 16. September 2012 20:11 > To: [email protected] > Subject: Re: [e4-dev] Persisted Application Model & Model Evolution > > I've not looked at the code but my understanding was that fragments are ONLY > merged on the first start and then the model is loaded from the persited state > only. > > So there's something strange here! > > Tom > > Am 15.09.12 16:35, schrieb Keimel, Christoph: > > 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 part3and drop > > it in stack1next 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 part3is contributed to stack2and stack2does 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 > > > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl geschäftsführer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
