Community
Participate
Working Groups
Build Identifier: I20100520-1730 (started in e4 community forum, see http://www.eclipse.org/forums/index.php?t=msg&th=168572&start=0&) There should be a way to clean the workbench deltas.xml on application startup or to not even create them, at all. There are three use-cases currently on my mind: 1. Application trouble-shooting. Let's say user is starting up an e4-based product, which (howsoever) shows some mis-behaviour. To reset an application to an initial model state (as when rolled out) would be a good idea. This could be utilized for example from 1st level support. 2. Enforced initial perspective If you want to always have the same perspective on each startup of the application (a so-to-say enforced initial perspective) using model-deltas will always be counter-productive. This is, you need some additional code (maybe in add-on or LifecycleManager) to make the intial perspective _initial_ again. 3. Confusing behavior Let's say, you have to choose a project on application startup, which will be the global context for everything you do when using the application. May be you utilize the "File-Open" menuitem to choose the project. After project is chosen, parts will open up programmatically and you can navigate through your application. On application restart, the deltas.xml is interpreted and all the views last-opened show up again. But you do not have any project, that is global context is missing. Now you're in the need to have some additional code, to ensure "all" the views get closed again, since the end-user might feel it being strange to have a table-view with no contents (thus, support is called, "all the project data are gone" :-) ). Another possible way could be, persisting <variable>'s in deltas.xml. But this could be a security-breach. Reproducible: Always
There's a variation of the second usecase, where only some elements should be (or the opposite: certain element elements shouldn't be) serialized out. It would be nice to have a 'transient' tag that would cause the delta-creator to ignore changes or discard the element. The two examples where this would be useful is for dynamically-generated editor parts which shouldn't be re-opened, or dynamically-installed handlers. A transient tag would still allow serializing out useful window layout changes such as window sizes, sash locations.
Created attachment 173936 [details] Patch This patch introduces: * clearPersistedState option which wipes the restore state * deltaRestore option which allows to turn off delta restore and uses standard xmi persistence (=> todo we need to think what impact this has on our model- fragment system) * fixes a problems with command-line parsing: => problem with arguments without a value => not using "-" for the keyname * fixes wrong String to boolean conversion
(In reply to comment #0) > Build Identifier: I20100520-1730 > > (started in e4 community forum, see > http://www.eclipse.org/forums/index.php?t=msg&th=168572&start=0&) > > There should be a way to clean the workbench deltas.xml on application startup > or to not even create them, at all. > > There are three use-cases currently on my mind: > > 1. Application trouble-shooting. > Let's say user is starting up an e4-based product, which (howsoever) shows some > mis-behaviour. To reset an application to an initial model state (as when > rolled out) would be a good idea. This could be utilized for example from 1st > level support. The attached patch fixes this. > > 2. Enforced initial perspective > If you want to always have the same perspective on each startup of the > application (a so-to-say enforced initial perspective) using model-deltas will > always be counter-productive. > This is, you need some additional code (maybe in add-on or LifecycleManager) to > make the intial perspective _initial_ again. > I think the new lifecycle support by using "lifeCycleURI:platform:/plugin/.../MyLF" option could help you out here. > 3. Confusing behavior > Let's say, you have to choose a project on application startup, which will be > the global context for everything you do when using the application. > May be you utilize the "File-Open" menuitem to choose the project. > After project is chosen, parts will open up programmatically and you can > navigate through your application. > On application restart, the deltas.xml is interpreted and all the views > last-opened show up again. But you do not have any project, that is global > context is missing. > Now you're in the need to have some additional code, to ensure "all" the views > get closed again, since the end-user might feel it being strange to have a > table-view with no contents (thus, support is called, "all the project data are > gone" :-) ). > Another possible way could be, persisting <variable>'s in deltas.xml. But this > could be a security-breach. My wild guess is that you can do this as well using the lifeCycleURI and remove all elements before the rendering happens.
Any thoughts on this? I'd like to release this change to HEAD for the next RC
(In reply to comment #4) > Any thoughts on this? I'd like to release this change to HEAD for the next RC It looks fine. Though I wonder if it's better to just search for '-clearPersistedState' and '-deltaRestore', instead of retrieving the arguments separately like '-clearPersistedState true' and '-deltaRestore true'.
(In reply to comment #5) > (In reply to comment #4) > > Any thoughts on this? I'd like to release this change to HEAD for the next RC > > It looks fine. Though I wonder if it's better to just search for > '-clearPersistedState' and '-deltaRestore', instead of retrieving the arguments > separately like '-clearPersistedState true' and '-deltaRestore true'. Good idea.
Created attachment 174127 [details] Patch This patch implements the suggestion from Remy to only search for the switches.
Created attachment 174128 [details] patch this one now also adjust the arg parsing to be consistent how to define cmd-switches by prefixing it with "-"
Do I need +1 or am I supposed to commit this simply?
Remy +1 (with a small name change to use -persistState instead of -saveAndRestore)
Are you sure the code is correct? E4Application // Delta save and restore boolean deltaRestore; value = getArgValue(E4Workbench.DELTA_RESTORE, appContext, true); deltaRestore = value == null || Boolean.parseBoolean(value); eclipseContext.set(E4Workbench.DELTA_RESTORE, Boolean.valueOf(deltaRestore)); As deltaRestore is a single argument I see no way of putting deltaRestore to false. I think correct would be: deltaRestore = value != null || Boolean.parseBoolean(value); This way the user would be required to set this launch paramter to get the save behavior. Currently the state is always persistent. I'm not quite sure if that is intended therefore I do not commit the change myself.
(In reply to comment #11) > As deltaRestore is a single argument I see no way of putting deltaRestore to > false. Indeed, this is a loophole that I didn't notice, unfortunately. Since the presence of the flag implies that deltas should be used (which is the default behaviour), having the flag there or not does not achieve nothing. It needs to be made to take an argument or the flag needs to be renamed. Though I understand Eric is investigating the possibility of loading/saving the model so the whole deltas idea may be canned.
+1 for a rename, e.g. deltaIgnore.
Created attachment 181055 [details] ResourceHandler patch v3
(In reply to comment #14) > Created an attachment (id=181055) [details] > ResourceHandler patch v3 Patch released to CVS HEAD. Thanks for bringing this to our attention, Lars.
Thanks Remy for reminding me to look into the coding to see the cause of this issue. :-)
Just to ensure everyone here gets the parameter right. It does NOT control whether your are saving/restoring the workbench state! It controls the type you use to save and restore it: a) Store deltas and apply them on startup using the Reconciler b) Serialize the complete model (this is similar to 3.x saveAndRestore(true)) and deserialize from XMI So IMHO the parameter name deltaIgnore is wrong! The correct name would be "-useDeltaRestore true|false" The replacement of saveAndRestore() is "-persistState true|false" but in 4.0 there was bug 324841 which already got fixed
@Tom: One clarification question: I think option a) would also be similar to saveAndRestore(true)) as only the way how the deltas are stored seems to be affected by this parameter If this correct?
Similar yes but not equal because 3.x saveAndRestore(true) e.g. will not recognize new UI-contribution - e.g. you contribute a new view to a perspective it won't show up until you reset the perspective - which is the main-advantage delta-restoring.
@Tom: thanks for the clarification, this is a cool new feature.
(In reply to comment #17) > So IMHO the parameter name deltaIgnore is wrong! The correct name would be > "-useDeltaRestore true|false" How about we just go back to -deltaRestore and make it take a boolean argument then? This way we're not really "breaking" anyone.
(In reply to comment #21) > How about we just go back to -deltaRestore and make it take a boolean argument > then? This way we're not really "breaking" anyone. I've changed it back to -deltaRestore and made it actually take a boolean argument for M3.
