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.

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

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?

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

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.

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.

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.

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

<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>

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>

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.

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.

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.

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.