| Custom IMarkerNavigationProvider [message #81068] |
Mon, 27 November 2006 09:30  |
Eclipse User |
|
|
|
Hi,
I've just implemented my own IMarkerNavigationProvider and found that
many opportunities for (re)using methods from
AbstractMarkerNavigationProvider or DiagramMarkerNavigationProvider
were missed, since several useful ones either were private or
protected final. E.g. DiagramMarkerNavigationProvider's
selectInDiagram is private, and AbstractMarkerNavigationProvider's
convertIdsToViews is protected final. Hence, a lot of my own methods
were either raw copies of existing code, or copies with very small
modifications. Basically, the only part I needed to change was to make
AbstractMarkerNavigationProvider's private recursiveConvertIdToView
method also look at the id of the view's element, so the (problem)
marker could contain ids for the view's element (which makes sense for
tools that operate on the semantic model, rather than the view).
Would it be possible to make some changes to these classes, to make
them more useful as superclasses of custom IMarkerNavigationProvider
implementations?
Hallvard
|
|
|
| Re: Custom IMarkerNavigationProvider [message #81144 is a reply to message #81068] |
Mon, 27 November 2006 11:30  |
| Eclipse User |
|
|
|
Hallvard,
Sounds reasonable to me. I would suggest you log a bugzilla providing
all the information you provided here.
Regards,
Cherie
Hallvard Trætteberg wrote:
> Hi,
>
> I've just implemented my own IMarkerNavigationProvider and found that
> many opportunities for (re)using methods from
> AbstractMarkerNavigationProvider or DiagramMarkerNavigationProvider
> were missed, since several useful ones either were private or
> protected final. E.g. DiagramMarkerNavigationProvider's
> selectInDiagram is private, and AbstractMarkerNavigationProvider's
> convertIdsToViews is protected final. Hence, a lot of my own methods
> were either raw copies of existing code, or copies with very small
> modifications. Basically, the only part I needed to change was to make
> AbstractMarkerNavigationProvider's private recursiveConvertIdToView
> method also look at the id of the view's element, so the (problem)
> marker could contain ids for the view's element (which makes sense for
> tools that operate on the semantic model, rather than the view).
>
> Would it be possible to make some changes to these classes, to make
> them more useful as superclasses of custom IMarkerNavigationProvider
> implementations?
>
> Hallvard
>
|
|
|
Powered by
FUDForum. Page generated in 0.03897 seconds
Home