Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Part's persisted state is lost even with apply="notexists"
Part's persisted state is lost even with apply="notexists" [message #1779178] Wed, 03 January 2018 15:44 Go to next message
Wernke zur Borg is currently offline Wernke zur BorgFriend
Messages: 42
Registered: December 2011
Member
Hi everybody,

I am contributing an e4 part to an RCP application model using a fragment with setting apply="notexist". Surprisingly, the part's persisted state is empty on application startup, in the @PostConstruct method. I am sure I am not using the -clearPersistedState argument.

Checking the persisted workbench.xmi I can see the persisted state has been saved correctly, but it is just not restored.

I am aware of topics E4 Perspective not persisted(A perspective contributed via fragment.e4xmi is not persisted) and Persisted state not persisted from a fragment?, so I assumed that setting notexist would prevent the workbench's persisted state to be overwritten with an empty persisted state from the fragment. But apparently this is not the case.

Any ideas here?

[Updated on: Thu, 04 January 2018 12:42]

Report message to a moderator

Re: Part's persisted state is lost even with apply="notexists" [message #1779235 is a reply to message #1779178] Thu, 04 January 2018 09:19 Go to previous message
Wernke zur Borg is currently offline Wernke zur BorgFriend
Messages: 42
Registered: December 2011
Member
I forgot to mention this is with Eclipse 4.6.

Debugging shows that in org.eclipse.e4.ui.internal.workbench.ModelAssembler the elements of the restored application model are overwritten with the corresponding elements from the fragment even if apply="notexists" is set.

Here comes the method processModelFragment():
	/**
	 * Contributes the given {@link MModelFragment} to the application model.
	 *
	 * @param fragment
	 *            the fragment to add to the application model
	 * @param contributorURI
	 *            the URI of the element that contributes this fragment
	 * @param checkExist
	 *            specifies whether we should check that the application model
	 *            doesn't already contain the elements contributed by the
	 *            fragment before merging them
	 * @return a list of the {@link MApplicationElement} elements that were
	 *         merged into the application model by the fragment
	 */
	public List<MApplicationElement> processModelFragment(MModelFragment fragment, String contributorURI,
			boolean checkExist) {

		E4XMIResource applicationResource = (E4XMIResource) ((EObject) application).eResource();

		List<MApplicationElement> elements = fragment.getElements();
		if (elements.size() == 0) {
			return new ArrayList<>();
		}

		for (MApplicationElement el : elements) {
			EObject o = (EObject) el;

			E4XMIResource r = (E4XMIResource) o.eResource();

			if (checkExist && applicationResource.getIDToEObjectMap().containsKey(r.getID(o))) {
				continue;
			}

			applicationResource.setID(o, r.getID(o));

			if (contributorURI != null)
				el.setContributorURI(contributorURI);

			// Remember IDs of subitems
			TreeIterator<EObject> treeIt = EcoreUtil.getAllContents(o, true);
			while (treeIt.hasNext()) {
				EObject eObj = treeIt.next();
				r = (E4XMIResource) eObj.eResource();
				if (contributorURI != null && (eObj instanceof MApplicationElement))
					((MApplicationElement) eObj).setContributorURI(contributorURI);
				applicationResource.setID(eObj, r.getInternalId(eObj));
			}
		}

		return fragment.merge(application);     // <=== here the fragment gets unconditionally merged into the app model !
	}


The flag checkExist is true if the fragment property apply="notexists". The mere effect of this is that the object ids in the application model are not overwritten with object ids from the fragment. But in the last line of this method the fragment is unconditionally merged into the application model, thereby wiping the persisted state of the part.

The conclusion for me is that the flag apply="notexists" only takes care that a part keeps its visual position in the workbench and is not duplicated (e.g. when the user moves it to a different PartStack) but still the part itself is replaced with the part from the fragment.

The consequence is that the persistedState is lost.

Is this intended behaviour and I am misunderstanding something here? Or should I raise a bug report?

Cheers, Wernke

[Updated on: Thu, 04 January 2018 12:43]

Report message to a moderator

Previous Topic:Event Broker vs Context Variables
Next Topic:Product Definition Dialog's hover scrolling
Goto Forum:
  


Current Time: Thu Apr 25 07:36:08 GMT 2024

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

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

Back to the top