Home » Eclipse Projects » Eclipse 4 » Problem with combination of restoring state + processing fragments with placeholders
| Problem with combination of restoring state + processing fragments with placeholders [message #1767332] |
Tue, 04 July 2017 17:03  |
 Erik Lundström
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi everyone,
I am working with migration an existing E3 product to being a pure E4 one. I am doing conceptual "proof-of-concepts" in a "testbed" github repository, which will also be my reference for the question posted here: https://github.com/Lulle74/e4ProofOfConcept
For the product I am working on, there will be several Perspectives, and many of the parts will be "common". Thus, I went for an approach with defining parts in the "shared elements" of the sole Window. I am using Placeholders within (element containers such as PartStacks in) my Perspectives, referring to the Parts.
Furthermore, there will be many app model fragments in the overall product. Typically, a fragment will both add Parts to the Window.sharedElements, and also Placeholders (to PartStacks of existing Perspectives), referring the Parts.
In my testbed repo, the following is in place:
- A project with a product
- A project with a feature
- A "main" plugin project (where among other things the Application.e4xmi resides)
- A "fragment" plugin project (containing one fragment.e4xmi)
Functionally, there are two handlers for "Reset perspective" and "Switch perspective" functionality in there. The main menu "Window" has the (handled) menu items that are connected to the commands and handlers. They work well.
Now, my problem has to do with the combination of:
* restoring the stored user state (ResourceHandler working on the "workbench.xmi")
* defining Placeholders in a fragment.e4xmi
I'd say that the "restore" (i.e. load the serialized xmi) works well in itself, but it's the subsequent handling of the fragment (in particular, the fragments containing Placeholders) that screws things up for me. I think it is best explained with a couple of images.
This image depicts the "Main" perspective at its defaults:
The Parts "Overview", "Details" and "Playground" are all defined in the Application.e4xmi in the shared elements of the Window, and below the perspective, there are placeholders referring them.
The "MonkeyView" on the other hand comes from a fragment.e4xmi.
If I'd run without the fragment (project), I can freely "move parts" around, even to new part stacks. The restore works like a breeze. But if I move the fragment placeholder for "MonkeyView" around (as exemplified in the image below), the problems will arise during a subsequent run of my product.
What happens, in turn, is:
- The "restore" does a pretty good job at first
- But, during the working of the (default) ModelAssembler, there will be the addition of an extra Placeholder, using the same shared element part.
The result after next startup is this:
As one can see, there is an excessive Placeholder, positioned in the (default) PartStack. This is not what I want.
I am using Eclipse Oxygen, and know exactly the part of code that I am a bit worried about: During the processing of the Placeholder fragment in the default ModelAssembler, the "merge" method of the StringModelFragmentImpl will be invoked. It will in turn take the "mergeIdList" route in my case, find the "default" PartStack (i.e. the one that I do not want in this case!) and finally add it to the "children" containment reference.
Could anyone suggest a way to sort out this unwanted extra placeholder? I guess having some kind of custom "post pass" would be one way forward, but I am a bit clueless of where would be the best suited place to put it. I guess I could customize the ModelAssembler myself, but am a bit reluctant to do so (would like to rely on the default behaviour of future versions, plus that the true problem might be in the StringModelFragmentImpl and/or ModelUtils, the way I see it).
I am sorry if similar problems have already been reported before, and would of course be very happy if someone could point me to an existing "best-practice"-solution.
Cheers,
Erik Lundström
[Updated on: Wed, 05 July 2017 09:10] Report message to a moderator |
|
| |
| Re: Problem with combination of restoring state + processing fragments with placeholders [message #1767475 is a reply to message #1767404] |
Thu, 06 July 2017 10:11  |
Erik Lundström
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Thanks for the reply and advice, Brian.
I tried out the two values ("notexists" and "initial", in turn), for a couple of different scenarios. My "findings" are the following. (I omit the "without restore" case (no workbench.xmi), which is trivial - all MModelFragments from an e4xmi fragment contribution will be effectively merged.)
apply="notexists"
All fragment contributions will always be merged here, using my approach (see image of my e4xmis at the end). So I'd say the level of "end success" is a matter of luck. For instance, these are undesired in my mind:
- If the restored state was that the placeholder has 'toberendered=false', the merge of the fragment will effectively overwrite this.
- If the restored state was that the placeholder was moved to another container, the merge of the fragment will add an excessive placeholder.
apply="initial"
Fragment contributions will never be merged. So of course, a restored state will prevail.
So one would assume that in order to restore user state properly, the apply="initial" would be the way forward.
But to bring the discussion a bit further, how should one consider the following, not totally unrealistic, prediction about the evolution of an application:
- restore of user state (i.e wb.xmi) must be supported (as far as possible)
- subsequent release of an app updates a fragment.e4xmi. Say, using my example as in the image of my fragment+application, that a new Part is added to the 'sharedElements' for instance. I can not see that this will be applied, using apply="initial".
If anyone has any thoughts on combining the requirement of restoring state + allowing an existing fragment to "change" between releases of a application/product, I'd be very interested to hear them!
This is an image of my fragment.e4xmi btw, with arrows indicating to which container each fragment goes.
|
|
| | | | |
Goto Forum:
Current Time: Wed Apr 24 14:25:16 GMT 2024
Powered by FUDForum. Page generated in 0.03946 seconds |
] 
Search
Help
Register
Login
Home
