| Re: [e4-dev] Persisted Application Model & Model Evolution |
Yes, these bugs are connected. If fragments are supposed to only be merged on the first start, than this issue will be solved. I opened Bug 389663 to track this side of the problem (and proposed a small fix). I also had problems with LazyStackRenderer and proposed a similar solution as Eric using UsageCrossRenderer to find all other references to the objectToBeReplaced. So my Bug 389624 is actually a duplicate of your Bug 382184. If Bug 389663 is the real problem, this could still be relevant, i.e. if it should be possible to explicitly replace model-elements with fragments. If not, than this branch of the code should probably throw an exception. Regards Christoph -----Ursprüngliche Nachricht----- @Christoph, do you see a relation to https://bugs.eclipse.org/bugs/show_bug.cgi?id=382184 Best regards, Kai > -----Original Message----- > From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] > On Behalf Of Tom Schindl > Sent: Sonntag, 16. September 2012 20:11 > To: e4-dev@xxxxxxxxxxx > 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: c.keimel@xxxxxxx > > <mailto:c.keimel@xxxxxxx> > > > > Geschäftsführer: Dipl.-Inf. (FH) Georg Engl > > UST-Id-Nr.: DE 131 175 644, HRB 80271 München > > > > > > > > > > > > _______________________________________________ > > e4-dev mailing list > > 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 > https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list |