API for efficient event dispatching is going to be added into debugger core.
It's purpose is:
1) to simplify the access to current active elements in the IDE (like current FileObject and editor pane) and
2) to make the events dispatching more efficient - reduce the number of listeners on context switching.
Created attachment 62669 [details]
The proposed API change.
Please review this API change. Separate issues will be filled for all debuggers to use this new API in order to improve
V1: I wonder why getCurrentEditorCookie() is neccessary? You already have methods that return JEditorPane and even the
line number. What else does EditorCookie give you?
V2: Why is getMostRecentEditor() private, but getMostRecentLineNumber() public? Should not they both either be private
or public? I would assume this to be symmetrical to getCurrentEditor() and getCurrentLineNumber().
V3: removePropertyChangeListener(mimeType, listener) is commented out, why?
V4: Some tests could be useful I think. Also it might be useful to describe a typical usage in javadoc, eg. what does
the class track, when are the events fired, who should be using this, etc.
Thanks for your review, Vita.
V1: getCurrentEditorCookie() is used to find org.openide.text.Line and current Documet. I've decided to provide just the
EditorCookie and not these derived objects. getCurrentLineNumber() is there just for convenience, since the line number
is the most typical information that is retrieved by all debuggers.
As I go through the usages, it looks like the second most wanted information is org.openide.text.Line, thus I'll
consider to add "Line getCurrentLine()" method and remove the getCurrentEditorCookie(), since Document can be retrieved
from getCurrentEditor(). It's not so nice, since it needs to be cast to StyledDocument and it's not apparent whether
JEditorPane will always contain StyledDocument or not. But if it's so, it can be documented.
V2: getMostRecentLineNumber() is used together with getMostRecentFile(), it's used by C/C++ debugger. Since we plan to
use that concept in JPDA debugger as well, I've realized now that we'll need also getMostRecentEditor() to be public.
I'll change it now so that it does not have to go through API review again in the future.
V3: I've extended removePropertyChangeListener(listener) to remove the listener also for all MIME types, so that it
works fine with WeakListeners. Therefore removePropertyChangeListener(mimeType, listener) became unnecessary, since
typically you need to unregister the listener completely and not from some specific MIME type only.
V4: I'll enhance the Javadoc with better description and usage. I've thought about tests; they would have to be GUI
tests, since we need the events from TopComponent.Registry.
I'll attach a reworked diff with "Line getCurrentLine()" method and extended Javadoc.
Created attachment 62797 [details]
The improved version of EditorContextDispatcher according to comments.
I've attached the modified version of EditorContextDispatcher. It contains following public methods now:
void addPropertyChangeListener(PropertyChangeListener l)
void addPropertyChangeListener(String MIMEType, PropertyChangeListener l)
void removePropertyChangeListener(PropertyChangeListener l)
Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE? (where
JEditorPane comes from EditorCookie.getOpenedPanes(). Thus JEditorPane.getDocument() should be the same as
EditorCookie.getDocument(), right?). Thanks.
> Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE?
Strictly speaking it does not have to, but since everybody is using the same implementation of EditorCookie I think you
can safely assume that this always holds true.
> Thus JEditorPane.getDocument() should be the same as EditorCookie.getDocument(), right?
Yes, even though EditorCookie does not enforce it in any way.
Thanks for the review.
Integrated into 'main-golden', available in NB_Trunk_Production #285 build
Log: #137005 - EditorContextDispatcher introduced for efficient handling of context change events.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.