Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Erik  undström is currently offline Erik undströmFriend
Messages: 11
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:
index.php/fa/29837/0/

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.

index.php/fa/29838/0/

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:
index.php/fa/29839/0/

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 #1767404 is a reply to message #1767332] Wed, 05 July 2017 16:06 Go to previous messageGo to next message
Brian de Alwis is currently offline Brian de AlwisFriend
Messages: 672
Registered: January 2012
Senior Member

Checkout the '<fragment apply=XXX>' attribute on the org.eclipse.e4.workbench.model extension point, specifically "initial" and "notexists".

Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.
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 Go to previous messageGo to next message
Erik  undström is currently offline Erik undströmFriend
Messages: 11
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:

  1. If the restored state was that the placeholder has 'toberendered=false', the merge of the fragment will effectively overwrite this.
  2. 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.
index.php/fa/29867/0/
Re: Problem with combination of restoring state + processing fragments with placeholders [message #1767923 is a reply to message #1767475] Wed, 12 July 2017 08:16 Go to previous messageGo to next message
Erik  undström is currently offline Erik undströmFriend
Messages: 11
Registered: July 2009
Junior Member
I think I have found a viable way forward. I think it may be a good idea to further divide a fragment.e4xmi into two fragments: the one "fragment.e4xmi" containing things like shared elements, commands and handlers (and maybe even stuff such as toolitems onto existing parts). The other "layoutfragment.e4xmi" (residing in the same plugin) will import the needed parts, and define perspective fragments and/or addition of part placeholders to existing perspectives.
Finally, stating apply="initial" for the layoutfragment.e4xmi when registering the extension should do the trick. On subsequent launches (i.e. when 'workbench.xmi' is used for restore purposes), the perspective layout fragments will not be read and thus "corrupting" the restored state.
The final piece of the puzzle will be to have a way to enforce "initial"-like startup. I guess it will not be deadly tricky to find a way to do that.

Does anyone else think that the "apply" attribute (with values 'always','notexists','initial') would not have been entirely misplaced on individual fragments as well? Maybe undesirable, since I guess that would mean introducing this concept/attribute on the EMF model (on MModelFragment), rather than keeping it in the Eclipse extensions world.
Re: Problem with combination of restoring state + processing fragments with placeholders [message #1767980 is a reply to message #1767923] Wed, 12 July 2017 14:00 Go to previous messageGo to next message
Brian de Alwis is currently offline Brian de AlwisFriend
Messages: 672
Registered: January 2012
Senior Member

Once the fragments have been knitted into the model, the fragments are discarded. So it doesn't make sense to have fragments with apply attributes.

If you want to force an "initial" like experience, don't persist the saved model (-persistState false) or discard the model on startup (-clearPersistedState)?


Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.
Re: Problem with combination of restoring state + processing fragments with placeholders [message #1768204 is a reply to message #1767980] Fri, 14 July 2017 14:38 Go to previous message
Erik  undström is currently offline Erik undströmFriend
Messages: 11
Registered: July 2009
Junior Member
Thanks Brian.
What I meant with "enforce intial-like startup" is the way I am thinking a new version of a released RCP-product will have to be managed. Say an existing fragment (like my thought-of "layoutfragment.e4xmi", having apply="initial") is updated between versions, to include new placeholders for instance. The same goes for adding a brand new fragment, having "apply=initial". It will not be picked up on first run of an updated RCP-product (if there is state on disk to be restored, obviously). So yes, I guess one has to find a way to "run once" with -clearPersistedState.
Previous Topic:Views open in wrong pane when using v3.x compatibilty layer
Next Topic:NatTable and context/dependency injection
Goto Forum:
  


Current Time: Sun Nov 19 21:57:53 GMT 2017

Powered by FUDForum. Page generated in 0.02139 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software