Bug 526256 - Model merging behaviour: Separate "apply" attribute for each MModelFragment in a MModelFragments container.
Summary: Model merging behaviour: Separate "apply" attribute for each MModelFragment i...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.7   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 562497
  Show dependency tree
 
Reported: 2017-10-19 05:16 EDT by Elias Vasylenko CLA
Modified: 2020-04-26 13:15 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elias Vasylenko CLA 2017-10-19 05:16:29 EDT
Currently there is a long standing problem with merging behaviour not being expressive enough to capture many common use-cases. For example:

- Allow users to open/close/move parts around the model and for that state to be persisted between runs, but at the same time if the part is updated they want the changes immediately merged in.

- Allow users to merge in updates to parts and addons without wiping their persisted state. (Though some persisted state may need to be updated with the model.)

I think there is a solution which is conceptually very simple and also straightforward to implement.

If each Model Fragment in a fragment definition specified its own merge strategy (as per the behaviour of apply="always|notexists|never|initial|whatever" in the plugin definition) we could approach those problems as follows, respectively:

- Define the parts in the shared elements area with apply="always", define placeholders in the model with apply="initial".

- Factor out data which actually needs to be persisted between runs to be managed by a separate addon with apply="initial". (A little awkward, but not too awful imo.)

At the moment a similar strategy can be implemented by including two or more separate fragment definitions in the plugin definition for a single bundle, but this is pretty cumbersome and there seem to be problems with import order when they both interdepend on one another.

I think adding first class support for this to them model will help people discover and think about these sorts of solutions, as I've seen many questions about this in the forums when trying to figure it out myself and useful answers are rare. It's even common for people to suggest reimplementing IModelResourceHandler!

I may be misunderstanding how it all works as I'm no expert, but the MModelFragments are separated out right there in the same place the "always" attribute is checked in the ModelAssembler, so it seems that it would be very simple to perform the check separately for each MModelFragment: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.workbench/src/org/eclipse/e4/ui/internal/workbench/ModelAssembler.java#n116

Thanks for reading, I hope this isn't something that has been discussed/dismissed before but I've not found anything on it. And I hope I've not overestimated the severity ;) but I do think this is hugely important.