Saving Part State [message #791285] |
Sun, 05 February 2012 15:35 |
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 15:57] Report message to a moderator
|
|
|
|
Re: Saving Part State [message #791741 is a reply to message #791285] |
Mon, 06 February 2012 07:57 |
Thomas Schindl Messages: 6651 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 #792777 is a reply to message #792750] |
Tue, 07 February 2012 11:52 |
Thomas Schindl Messages: 6651 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 14:32 |
Thomas Schindl Messages: 6651 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.
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04627 seconds