[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Persisted Application Model & Model Evolution
|
@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
> > e4-dev@xxxxxxxxxxx
> > 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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
