Community
Participate
Working Groups
I've just been writing a very simple editor, and it took me ages to work out that I needed to call setSite(site) in order to avoid the NullPointerException I was getting, and I had to ask in the newsgroup in order to work out to call setInput(input). Presumably most editors will want to do this, so either it should be documented clearly within the init() documentation that it's a good thing to do, or perhaps the default behaviour should be changed so that it's not required. I confess to still being an almost complete newbie to SWT/JFace, but this kind of thing (which gives NPEs which really don't give much hint to the newbie as to what they've done wrong) makes the learning curve very steep indeed.
I've seen this problem arise may times with developers creating editors (and not just first timers - its easy to forget to make these two calls). The EditorPart.init method doc does state these two methods need to be call, but obviously that is not enough. We should change the API here to fix this problem. Maybe we could make the init method final. In the EditorPart.init method, we could call the abstract method validateEditorInput which could throw a PartInitException if the subclass cannot accept the input. We could then set the site and editor input. Then maybe call something like an abstract "finishInit" method to allow the subclass to complete there initialization process. We could then make setSite and setInput non-accessible outside the framework. Nick, can you assign to me if you agree with this and want the changes to go ahead. This would be a broken API change. But I see this as beneficial to developers.
Does the documentation really say it? Here's what I got from the online 2.1 docs: <quote> Initializes this editor with the given editor site and input. This method is automatically called shortly after part construction; it marks the start of the part's lifecycle. The IWorkbenchPart.dispose method will be called automically at the end of the lifecycle. Clients must not call this method. Implementors of this method must examine the editor input object type to determine if it is understood. If not, the implementor must throw a PartInitException. </quote> I took that to mean "Do whatever your particular editor needs to use the given input and site." Stating explicitly (if the API doesn't get changed or maybe until it does) "during this method you should call setSite and setInput" would be good :)
Awaiting comment from Nick.
Can we do it in a non-breaking way? E.g.: change init to be non-abstract, and call a new method to check the input, which can be overridden? public void init(IEditorSite site, IEditorInput input) throws PartInitException { checkInput(input); setSite(site); setInput(input); } protected void checkInput(IEditorInput input) throws PartInitException { // do nothing by default }
Jon - The doc on EditorPart.init (the class here, not the interface IEditorPart) does state that setSite and setInput must be call. Its an implementation detail for that class. Nick - Yep, that is possible and we could update the doc about this. However, if we end up breaking other APIs on editor part for other reasons, I would like to then fix this problem properly by breaking the init api method.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
