| Re: [platform-ui-dev] How to rename a view ID on an namespace-restructuring update ? |
Hi,
Yes a processor is executed all time the only possibility is to say that
it should not run on a clean workspace. So you can not avoid the
processor being created but you can store in the model that you have
already processed this workspace (you could naturally also use a
preference!). So you break the processing as early as possible.
So I think about something like this:
> public class Migrator {
>
> @Execute
> public void migrate(MApplication app, EModelService ms) {
> long t1 = System.currentTimeMillis();
> if (!app.getPersistedState().containsKey("tm_terminal_restructured")) {
>
> app.getPersistedState().put("tm_terminal_restructured", "done");
>
> ms.findElements(app, MPart.class, EModelService.ANYWHERE, e -> "my.old.view.id".equals(e.getElementId()))
> .forEach(e -> {
> e.setElementId("my.new.view.id");
> e.setIconURI("platform:/plugin/my.new.view/icons/my-view.png");
> });
>
> ms.findElements(app, MPlaceholder.class, EModelService.ANYWHERE,
> e -> "my.old.view.id".equals(e.getElementId())).forEach(e -> e.setElementId("my.new.view.id"));
>
> }
> long t2 = System.currentTimeMillis();
> System.err.println("Cleanup took: " + (t2 - t1));
> }
> }
So the slow down for:
initial restore:
1. Create an instance of Migrator
2. Do the hash-look up
3. Traverse the model which is already in memory
=> In my test 2+3 takes less then 5ms - I can not really measure the
performance hit caused by the bundle activation , ...!
=> You can get slightly faster (~3ms) if you do the search at the EMF
level but I don't think this is justifies it
each restore is:
1. Create an instance of Migrator
2. Do the hash-look up
=> In my test 2 takes less then 1ms - I can not really measure the
performance hit caused by the bundle activation , ...!
And before someone mentions it - I know currentTimeMillis is not the
best way to do performance measuring but anyways ;-)
It like to point out that this fixup needs to be used with caution -
maybe we can in 4.6 provide a general workbench service you can
contribute to so that not everyone who want
Tom
On 08.05.15 08:38, Oberhuber, Martin wrote:
> Hi Tom,
>
>
>
> Your approach sounds very interesting !
>
>
>
> But I’m concerned that the migration code registered through the e4
> extension point would be _/always/_ executed regardless of whether it’s
> needed or not.
>
> That would obviously degrade startup performance which feels like a
> no-go to me.
>
>
>
> Or is there any possibility binding execution of such migration code to
> a condition like “old view ID is being processed” while an old workspace
> is being opened ?
>
>
>
> Thanks,
>
> Martin
>
> --
>
> *Martin Oberhuber*, SMTS / Product Owner – Development Tools, *Wind River*
>
> direct +43.662.457915.85 fax +43.662.457915.6
>
>
>
> *From:*platform-ui-dev-bounces@xxxxxxxxxxx
> [mailto:platform-ui-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Tom Schindl
> *Sent:* Thursday, May 07, 2015 7:44 AM
> *To:* Eclipse Platform UI component developers list.
> *Subject:* Re: [platform-ui-dev] How to rename a view ID on an
> namespace-restructuring update ?
>
>
>
> You can ship a model processor through the e4 extension point and walk
> the model removing the references or even adjust the id pointing to the
> new view id
>
>
>
> Tom
>
> Von meinem iPhone gesendet
>
>
> Am 07.05.2015 um 00:14 schrieb Oberhuber, Martin
> <Martin.Oberhuber@xxxxxxxxxxxxx <mailto:Martin.Oberhuber@xxxxxxxxxxxxx>>:
>
> Hi Platform/UI experts,
>
>
>
> As part of the TM Terminal restructuring that we’ve done recently,
> we’ve changed the ID of a view to the new namespace.
>
>
>
> This causes issues when the view was active in a perspective when
> the update is applied:
> After Eclipse restarts, the now-obsolete view shows up in an error
> state.
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=466644
>
>
>
> Do you see any way we could avoid this ? For instance, provide
> plugin.xml markup that would specify the view as “no longer existant
> thus close on restart”.
>
> We thought about a PerspectiveListener, but we’d like to avoid
> unnecessary plugin activation if possible.
>
> If you have any thought or idea, we’d really appreciate a comment on
> the bug !
>
>
>
> Thanks,
>
> Martin
>
> --
>
> *Martin Oberhuber*, SMTS / Product Owner – Development Tools, *Wind
> River*
>
> direct +43.662.457915.85 fax +43.662.457915.6
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx <mailto:platform-ui-dev@xxxxxxxxxxx>
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev