Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Saving Part State
Saving Part State [message #791285] Sun, 05 February 2012 10:35 Go to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
In the 3.x API there was the method

void IViewPart.saveState(IMemento memento);

I haven't been able to figure out how to replace that in e4. I've tried to save away my private view state like so:

part.getPersistedState().put("mykey", "myvalue")

and then, in a @PostConstruct method to do

part.getPersistedState().get("mykey");

however, I always get back a null value. I've tried to save the state in a @PreDestroy method, which got called, but the put() had no effect. I then tried to put a @PreSave annotation on the method, but in that case, the method didn't even get called.

Any Ideas?

greets, Thomas

[Updated on: Sun, 05 February 2012 10:57]

Report message to a moderator

Re: Saving Part State [message #791417 is a reply to message #791285] Sun, 05 February 2012 15:00 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1048
Registered: July 2009
Senior Member

Hi Thomas,

please have a look at Eclipse 4 and Preferences Tutorial.

I try to describe the usage of Preferences in this tutorial. Let me know if that solves your problem.

Best regards, Lars
Re: Saving Part State [message #791741 is a reply to message #791285] Mon, 06 February 2012 02:57 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Yes setting the state in @PreDestroy is the correct solution. If this is
not working please file a bug. Just to make sure you don't specify clean
when starting up the next time?

Tom

Am 05.02.12 16:35, schrieb Thomas äder:
> In the 3.x API there was the method
>
> void IViewPart.saveState(IMemento memento);
>
> I haven't been able to figure out how to replace that in e4. I've tried
> to save away my private view state like so:
>
> part.getPersistedState().put("mykey", "myvalue")
>
> and then, in a @PostConstruct method to do
>
> part.getPersistedState().get("mykey");
>
> however, I always get back a null value. I've tried to save the state in
> a @PreDestroy method, which got called, but the put() had no effect. I
> then tried to put a @PreSave annotation on the method, but in that case,
> the method didn't even get called.
>
> Any Ideas?
>
> greets, Thomas
Re: Saving Part State [message #791742 is a reply to message #791417] Mon, 06 February 2012 02:58 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Preferences are not the correct way to save and restore the state of a
view - this should be done using the persistedState.

Tom

Am 05.02.12 21:00, schrieb Lars Vogel:
> Hi Thomas,
>
> please have a look at
> http://www.vogella.de/articles/Eclipse4Preferences/article.html.
>
> I try to describe the usage of Preferences in this tutorial. Let me know
> if that solves your problem.
>
> Best regards, Lars
Re: Saving Part State [message #791766 is a reply to message #791742] Mon, 06 February 2012 03:33 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Thanks Tom,

I've noticed that actually, the save/read mechanism works, but that the widgets are already disposed in the @PreDestroy. But widget state is exactly what I'm trying to save. Is there an earlier callback I can use where the widgets are still there?

Thomas
Re: Saving Part State [message #791790 is a reply to message #791766] Mon, 06 February 2012 04:01 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Hi,

Hm - that is not different in 3.x, not? If you try to access the widgets
inside the ViewPart#dispose method they are already disposed.

There's no other event i think. So I guess you'll have to set the value
whenever a widget changes its value, or keep the state in an internal
variable and move it to the persisted state on @PreDestroy.

Tom

Am 06.02.12 09:33, schrieb Thomas äder:
> Thanks Tom,
>
> I've noticed that actually, the save/read mechanism works, but that the
> widgets are already disposed in the @PreDestroy. But widget state is
> exactly what I'm trying to save. Is there an earlier callback I can use
> where the widgets are still there?
>
> Thomas
Re: Saving Part State [message #791833 is a reply to message #791790] Mon, 06 February 2012 05:02 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Yes, but the widgets were usable in the saveState(...) method, see for example the class org.eclipse.ui.views.markers.internal.TableView. If I have no callback that still has the widgets available, I'd have to track all relevant widget state all the time and keep a copy in my view class. I definitely don't want to do that.
Re: Saving Part State [message #791869 is a reply to message #791833] Mon, 06 February 2012 05:54 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Ok - I see in 3.x the saveState-method is executed, when the workbench
shutsdown.

It looks to me we are not having such an event yet which marks a major
regression compared to 3.x views.

I'm not sure why this save is only executed on shutdown and I think we
should more generally provide a callback annotation exectued when the
view closes like @PersitState.

I think it should be exectued in the diposeWidget()-method of a
ContributedPartRender. I guess another option for you until then is to
attach a DisposeListener on the top-level Composite because at this
moment the children are not yet disposed.

Tom

Am 06.02.12 11:02, schrieb Thomas äder:
> Yes, but the widgets were usable in the saveState(...) method, see for
> example the class org.eclipse.ui.views.markers.internal.TableView. If I
> have no callback that still has the widgets available, I'd have to track
> all relevant widget state all the time and keep a copy in my view class.
> I definitely don't want to do that.
Re: Saving Part State [message #792116 is a reply to message #791869] Mon, 06 February 2012 11:29 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Hmhhhh...I guess I'll just leave that part out for the moment. I humbly suggest that only eating your own dogfood (i.e. port the Eclipse SDK to nativ e4) will make sure that no essential parts are missing.

Thomas
Re: Saving Part State [message #792155 is a reply to message #792116] Mon, 06 February 2012 12:20 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Frankly - that will never happen - and as outlined is not always the
desired thing because doing things a bit different (doing the save not
only on workbench shutdown) would not happen then.

Tom

Am 06.02.12 17:29, schrieb Thomas äder:
> Hmhhhh...I guess I'll just leave that part out for the moment. I humbly
> suggest that only eating your own dogfood (i.e. port the Eclipse SDK to
> nativ e4) will make sure that no essential parts are missing.
>
> Thomas
Re: Saving Part State [message #792699 is a reply to message #792155] Tue, 07 February 2012 04:53 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
<rant>
Then how are you going to convince anybody that an IDE-class application can be built on top of e4? If you can't convince your own people to port to the e4 API, why should anybody else? I've been working on my little part here for about 4 days and already I've found a pretty glaring functional gap between 3.x and e4. That does not really convince me that e4 will be ready from prime time with the Juno release. Hmhhh...
</rant>
Re: Saving Part State [message #792714 is a reply to message #792699] Tue, 07 February 2012 05:18 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Have you ever looked at how big the Eclipse Code base is? Who the hell
would pay for this rewrite? I'm not responsible for all those developers
but would be suprised if it will happen.

That's why there's the compat layer providing you exactly this kind of
support.

In the past we made the fault to merge to many functionality into the
Eclipse Code base causing us maintenance nightmare simply because one
product wanted it.

In e4 we are turning this around we provide only minimalistic API at the
e4 level (Model + Service API) but allow you to extend the concepts e.g.
to build something like an IDE (we allow you to extend our Meta-Model to
add new concepts - take a look at the SimpleIDE it the git-repo to see
how one can extend the e4 application model.

As an example for this is that you could solve this very problem by
(though still agree as stated before that this functionality should be
built into the framework):
a) defining your own annotation
b) provide your own ContributedPartRenderer
c) overload the disposeWidget-method and call the annotated method

The main target for E4AP (that's what you called e4) is RCP like
applications and this core modules will never provide more than that.

The next focus could be to work on API above this layer make writing IDE
like applications possible but we simply don't have the resources.

Your attitude of not even filing a bug for missing functionality is not
really help us in this respect.

Final word. I don't expect E4AP provide you all the support you want
when writing an IDE-class applications (e.g. there's no direct support
for editor registration) provided in Juno timeframe and I don't see us
having advertised e4 for IDEs whereas we have for RCP apps.

The missing functionality we are discussing here is something that is
needed for RCP like apps and would have been willing to donate my spare
time to fill the gap but not without minimal help from you on at least
specifying the minimal behavior in a bug report.

Tom

Am 07.02.12 10:53, schrieb Thomas Mäder:
> <rant>
> Then how are you going to convince anybody that an IDE-class application
> can be built on top of e4? If you can't convince your own people to port
> to the e4 API, why should anybody else? I've been working on my little
> part here for about 4 days and already I've found a pretty glaring
> functional gap between 3.x and e4. That does not really convince me that
> e4 will be ready from prime time with the Juno release. Hmhhh...
> </rant>
Re: Saving Part State [message #792750 is a reply to message #792714] Tue, 07 February 2012 06:11 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Tom Schindl wrote on Tue, 07 February 2012 05:18
Have you ever looked at how big the Eclipse Code base is? Who the hell
would pay for this rewrite? I'm not responsible for all those developers
but would be suprised if it will happen.

Why, IBM, of course Wink

Quote:


As an example for this is that you could solve this very problem by
(though still agree as stated before that this functionality should be
built into the framework):
a) defining your own annotation
b) provide your own ContributedPartRenderer
c) overload the disposeWidget-method and call the annotated method



Thanks, that's helpful

Quote:


Your attitude of not even filing a bug for missing functionality is not
really help us in this respect.

Final word. I don't expect E4AP provide you all the support you want
when writing an IDE-class applications (e.g. there's no direct support
for editor registration) provided in Juno timeframe and I don't see us
having advertised e4 for IDEs whereas we have for RCP apps.

The missing functionality we are discussing here is something that is
needed for RCP like apps and would have been willing to donate my spare
time to fill the gap but not without minimal help from you on at least
specifying the minimal behavior in a bug report.


Dude, I'm not your enemy. I haven't filed a bug because I don't know if it's a bug, missing functionality or just that I don't know what I'm doing. The whole dependency injection/modeled workbench stuff makes the framework less discoverable; you can't just browse along some API. Since a lot of the Javadoce is boilerplate right now ("the meaning of the XXX attribute isn't clear, there really should be more of a description" Wink), it's not always easy to figure out how it's supposed to work.
Re: Saving Part State [message #792777 is a reply to message #792750] Tue, 07 February 2012 06:52 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
I don't see you as an enemy but you started your last reply with <rant>
and I replied that ranting doesn't help us at all.

We need input - and this input has to be provided through bugzillas the
team can't browse the newsgroup and extract the informations on their own.

If you find missing functionality, documentation ... we are always happy to:
* receive bugzillas
* patches with implementation inside a bugzilla

You can see the missing of a feature a possibility for you to move the
framework into a direction.

Tom

Am 07.02.12 12:11, schrieb Thomas Mäder:
> Tom Schindl wrote on Tue, 07 February 2012 05:18
>> Have you ever looked at how big the Eclipse Code base is? Who the hell
>> would pay for this rewrite? I'm not responsible for all those developers
>> but would be suprised if it will happen.
>
> Why, IBM, of course ;)
>
> Quote:
>> As an example for this is that you could solve this very problem by
>> (though still agree as stated before that this functionality should be
>> built into the framework):
>> a) defining your own annotation
>> b) provide your own ContributedPartRenderer
>> c) overload the disposeWidget-method and call the annotated method
>
>
> Thanks, that's helpful
>
> Quote:
>> Your attitude of not even filing a bug for missing functionality is not
>> really help us in this respect.
>>
>> Final word. I don't expect E4AP provide you all the support you want
>> when writing an IDE-class applications (e.g. there's no direct support
>> for editor registration) provided in Juno timeframe and I don't see us
>> having advertised e4 for IDEs whereas we have for RCP apps.
>>
>> The missing functionality we are discussing here is something that is
>> needed for RCP like apps and would have been willing to donate my spare
>> time to fill the gap but not without minimal help from you on at least
>> specifying the minimal behavior in a bug report.
>
>
> Dude, I'm not your enemy. I haven't filed a bug because I don't know if
> it's a bug, missing functionality or just that I don't know what I'm
> doing. The whole dependency injection/modeled workbench stuff makes the
> framework less discoverable; you can't just browse along some API. Since
> a lot of the Javadoce is boilerplate right now ("the meaning of the XXX
> attribute isn't clear, there really should be more of a description"
> ;)), it's not always easy to figure out how it's supposed to work.
Re: Saving Part State [message #794647 is a reply to message #792750] Thu, 09 February 2012 09:32 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
Filed as https://bugs.eclipse.org/bugs/show_bug.cgi?id=371087

Tom

Am 07.02.12 12:11, schrieb Thomas Mäder:
> Tom Schindl wrote on Tue, 07 February 2012 05:18
>> Have you ever looked at how big the Eclipse Code base is? Who the hell
>> would pay for this rewrite? I'm not responsible for all those developers
>> but would be suprised if it will happen.
>
> Why, IBM, of course ;)
>
> Quote:
>> As an example for this is that you could solve this very problem by
>> (though still agree as stated before that this functionality should be
>> built into the framework):
>> a) defining your own annotation
>> b) provide your own ContributedPartRenderer
>> c) overload the disposeWidget-method and call the annotated method
>
>
> Thanks, that's helpful
>
> Quote:
>> Your attitude of not even filing a bug for missing functionality is not
>> really help us in this respect.
>>
>> Final word. I don't expect E4AP provide you all the support you want
>> when writing an IDE-class applications (e.g. there's no direct support
>> for editor registration) provided in Juno timeframe and I don't see us
>> having advertised e4 for IDEs whereas we have for RCP apps.
>>
>> The missing functionality we are discussing here is something that is
>> needed for RCP like apps and would have been willing to donate my spare
>> time to fill the gap but not without minimal help from you on at least
>> specifying the minimal behavior in a bug report.
>
>
> Dude, I'm not your enemy. I haven't filed a bug because I don't know if
> it's a bug, missing functionality or just that I don't know what I'm
> doing. The whole dependency injection/modeled workbench stuff makes the
> framework less discoverable; you can't just browse along some API. Since
> a lot of the Javadoce is boilerplate right now ("the meaning of the XXX
> attribute isn't clear, there really should be more of a description"
> ;)), it's not always easy to figure out how it's supposed to work.
Re: Saving Part State [message #797569 is a reply to message #794647] Mon, 13 February 2012 11:51 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Thanks, Tom.
Re: Saving Part State [message #797601 is a reply to message #797569] Mon, 13 February 2012 12:25 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5242
Registered: July 2009
Senior Member
And just fixed with

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f2a8ce2a9c2725653391ee3326262a984a9fa896

So in the next builds you should have support for this new annotation.
Any other feature gaps you noticed?

Tom

Am 13.02.12 17:51, schrieb Thomas Mäder:
> Thanks, Tom.
Re: Saving Part State [message #802912 is a reply to message #797601] Mon, 20 February 2012 11:48 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
great!
Re: Saving Part State [message #809071 is a reply to message #792699] Tue, 28 February 2012 07:59 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

And just as an aside, Eclipse 4 RCP API *will not* be delivered for Juno. That's not what we're providing. As you've noticed, it's not complete yet Smile

We are providing the Eclipse 4.2 Workbench which includes the standard 3.x workbench services and part of its implementation based on the workbench model+renderers and DI from Eclipse 4.

In 4.3 we'll be looking at making the Eclipse 4 RCP API available. As Tom mentioned we do need feedback in the form of bugs to cover off holes in the Eclipse 4 RCP story.

PW




Re: Saving Part State [message #826845 is a reply to message #809071] Thu, 22 March 2012 11:20 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
So to be perfectly clear: if we need stuff that is not implemented yet (like dynamic context menus, for example), we cannot be based on the e4 API, but must program against the 3.x API?
Re: Saving Part State [message #827471 is a reply to message #826845] Fri, 23 March 2012 07:26 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

To get something like o.e.ui.menus/menuContribution/dynamic you need to program to the 3.x APIs and include the 4.2 Workbench as well. In Eclipse 4 right now you can update the MPopupMenu model directly, but the tightly bound lifecycle is no implemented. It's possible something like this could be done with an MDynamicItem or MFactoryItem model element in the future.

But that's just one example. If you use any of the o.e.ui extension points, the Preference dialog, about, the progress view, or anything currently in o.e.ui.ide you would need the 4.2 Workbench.

PW


Re: Saving Part State [message #829481 is a reply to message #827471] Mon, 26 March 2012 06:56 Go to previous messageGo to next message
Thomas  Mäder is currently offline Thomas Mäder
Messages: 46
Registered: July 2009
Member
Would that entail that we have to run as an IDEApplication? Would we have to implement our parts as 3.x ViewParts?
Re: Saving Part State [message #831273 is a reply to message #829481] Wed, 28 March 2012 13:41 Go to previous message
Brian de Alwis is currently offline Brian de Alwis
Messages: 242
Registered: July 2009
Senior Member
No, you don't have to be an IDEApplication. (you don't have to include org.eclipse.ui.ide), but you do have to launch the workbench. You'll use the regular E3.x APIs for RCP app.
Previous Topic:Popup menu disapears after reopen a part
Next Topic:Having problems running 3.7 RCP app in e4
Goto Forum:
  


Current Time: Thu Jul 24 19:00:24 EDT 2014

Powered by FUDForum. Page generated in 0.09469 seconds