Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Implementation of e4 editors(Help to novice: how create a custom editor)
Implementation of e4 editors [message #1094918] Mon, 26 August 2013 11:42 Go to next message
Pim van Nierop is currently offline Pim van NieropFriend
Messages: 7
Registered: August 2013
Junior Member
Hello everone,

One thing that confuses me as a novice in Elipse 4 RCP developent (among many others Wink). I am running a Eclipse RCP application configured as 3.x compatibility project as described in the "tutorial-eclipse-rcp-e4-with-3-x-views-like-project-explorer-properties-etc" blog entry (I was not allowed to use the relevant URL). The derired behavior would be that a double click on a file in the 3.x. Project Explorer view will open a new Editor Part that ends up in the common editors area. To get this behavior I created an extension to org.eclipse.ui.editors that points to an implementing class that must extend EditorPart (or implement IEditorPart). This structure forces me to implement all kinds of @Override methods that relate to the initialization (init()) and persistence behavior (f.i. doSave()). This approach is described in detail on the Juno doumentation pages.

In many references on the web, for instance on the Vogella site (www.vogella.com/articles/Eclipse4Editor/article.html), it is however mentioned that an e4 editor can however be a POJO that will behave as an editor part by the use of the MDirtyable flag and @Persist annotations.

For me it is difficult to understand how bring together these two worlds of editor implementation being forces implementation of inherited methods versus the annotation/Application model way. Can anyone point me in the right direction?

Thnx for your patience,
Pim
Re: Implementation of e4 editors [message #1095213 is a reply to message #1094918] Mon, 26 August 2013 19:51 Go to previous messageGo to next message
Eric Moffatt is currently offline Eric MoffattFriend
Messages: 118
Registered: July 2009
Senior Member
This is as yet a mostly unexplored area. We've added a new entry to the 'org.eclipse.ui.views' extension point called 'e4view' which will allow you to use a POJO based implementation but contribute the view using the legacy extension point. We haven't done this for editors yet but will likely do so in Luna. Once in place you'll be able to write the implementation of your editor using all the cool DI stuff.

What's slowing this down a bit is that we need to ensure that the result meshes well with the existing platform API; for example we need to be able to 'grow' an EditorReference for these editors which will mean also growing a WorkbenchEditorPart to act as a front to the rest of the eclipse API...
Re: Implementation of e4 editors [message #1095544 is a reply to message #1095213] Tue, 27 August 2013 07:44 Go to previous messageGo to next message
Pim van Nierop is currently offline Pim van NieropFriend
Messages: 7
Registered: August 2013
Junior Member
Hi Eric,

Ok, I consider this to be a work-in-progress then. I will revisit the DI method for editor parts at a later time point. Thanks for this quick answer; for a beginner it is kinda hard to see if one is heading down a wrong implemtation path or not.

Tnx, Pim
Re: Implementation of e4 editors [message #1097105 is a reply to message #1095544] Thu, 29 August 2013 08:34 Go to previous message
Pim van Nierop is currently offline Pim van NieropFriend
Messages: 7
Registered: August 2013
Junior Member
For the record, I wanted to state here that I managed to bring together the e3 and e4 worlds using the bridge feature in the e4 tools. I describe this in this forum post. Maybe other beginners are helped with this too.
Previous Topic:Dependency Injection problem
Next Topic:Show Intro after start
Goto Forum:
  


Current Time: Tue Mar 19 08:36:20 GMT 2024

Powered by FUDForum. Page generated in 0.02443 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top