Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top