Bug 53454 - Support for hyperlink feature
Support for hyperlink feature
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: -- Other --
4.x
All All
: P1 (vote)
: 4.x
Assigned To: apireviews
issues@editor
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 22:54 UTC by Miloslav Metelka
Modified: 2007-11-05 13:44 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
:


Attachments
Diff of arch document and the SPI interface (6.79 KB, patch)
2005-01-14 22:55 UTC, Miloslav Metelka
Details | Diff
Full diff of the intended change (36.56 KB, patch)
2005-01-18 09:02 UTC, Miloslav Metelka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2005-01-14 22:54:19 UTC
The hyperlink feature provides simple and
efficient navigation between java classes by
turning the text under the mouse cursor into a
clickable hyperlink.
The feature is active when a Ctrl key is pressed
and held.
Typical scenario:
1. User is editing a java source
2. There is a piece of code e.g. "var.toString();"
and the user would like to inspect the code of the
"toString()" method.
3. The user moves the cursor over the "toString"
and presses and holds Ctrl key which causes the
"toString" to become blue-colored and underlined
hyperlink (just like a link in an html browser).
The mouse cursor turns into "hand" as well.
4. Hyperlink can be clicked which moves the cursor
to the definition of the method (existing "Goto
Declaration" action gets invoked in the java editor).
We would like to integrate the feature into promoE.

In order to support this feature we need to create
a small SPI which the providers of the
hyperlinking functionality (editors for the
particular mime-types such as java editor) would
implement.
It needs to be decided whether:
1. Whether the place under the mouse cursor is
suitable for hyperlinking
2. Determine the span of the hyperlink in the text.
3. Implement the action which gets triggered after
the hyperlink gets clicked by the user.

The rest of the feature implementation will be a
private implementationn in the editor core.

I plan to create "under development" SPI.
I would like to ask the DevRev team for review.
I'm attaching the diff containing the interface to
be implemented and the arch document changes.
Later I can attach the complete diff of the
feature if desired.
As the feature delegates to existing functionality
(tokenization for span resolution and
goto-declaration action as a click action) we
initially plan to use just functional tests for
testing the feature.
Comment 1 Miloslav Metelka 2005-01-14 22:55:48 UTC
Created attachment 19711 [details]
Diff of arch document and the SPI interface
Comment 2 Miloslav Metelka 2005-01-17 09:28:08 UTC
I would also like to create an implementation dependency between
(generic) Editor module and the Editor Library module. That would
allow to support the following functionality:
Class HyperlinkProviderManager that allows to lookup the hyperlink
providers for a particular mime-type is defined in the Editor Library
module. There is HyperlinkProviderManager.getDefault() static method
that should find an implementation (e.g.
LayerHyperlinkProviderManager) that searches the HyperlinkProvider
instances defined in the xml layer (in
Editors/<mime-type>/HyperlinkProviders). The
LayerHyperlinkProviderManager however needs to be defined in the
Editor module (not the Editor Library which is NB IDE independent).

To implement LayerHyperlinkProviderManager in Editor module the
HyperlinkProviderManager class would need to reside in a public
package of the Editor Library or there must be an implementation
dependency between the Editor module and the Editor Library module.
IMHO the implementation dependency would be better in this case because:
1) Editor and Editor Library modules are tight anyway and they are in
the same cluster.
2) There should be no more implementations of the
HyperlinkProviderManager (except a one for the Standalone Editor which
is however irrelevant in this discussion) so there is no reason to
expose the HyperlinkProviderManager class to other modules than the
Editor module.

I would like the reviewers to give me their opinion on this topic as
well. Thanks.
Comment 3 Miloslav Metelka 2005-01-17 16:46:38 UTC
After brainstorming with Hrebejk and Petr N. we have concluded that in
the shortterm the implementation dependency is probably fine but in
the longterm there could be a "mime-type lookup" implemented that
would support a lookup of kind

List<cls> lookup(String mimeType, Class cls);

plus a listening for changes in the result.
 I'll try to work out this idea for promoF.

I would like to ask Hrebejk and Petr N. for review. Thanks.
Comment 4 Miloslav Metelka 2005-01-18 09:02:24 UTC
Created attachment 19736 [details]
Full diff of the intended change
Comment 5 Tomas Pavek 2005-01-18 09:15:16 UTC
Looks good to me.
Comment 6 Petr Hrebejk 2005-01-18 09:41:18 UTC
For record for later changes: When reviewing the change with Mila and
Petr Nejedly we decided t go with the implementation dependency
between Editor and EditorLibrary form now.
But the situation seems to be that the EditorLibrary module needs some
services provided by the environment. By environment I mean the IDE or
some other application the EditorLibrary is used in. By services I
mean things like searching for/registering information about some
functionality. It may be the HyperlinkProviderManager, settings,
anotation providers, etc. I.e. all the things which have to depend on
the application the EditorLibrary is used in.
It might be worth of separating all these things it one or more
packages e.g. org.netbeans.spi.editor.library.environment. Javadoc of
this package would explicitly state out that the classes have to by
implemented if and only if the user is working on integration of the
editor into some application and that there is no need of touching
these classes if only the editor functionality in IDE has to be extended.

Such separation should help to keep the design clean and to avoid the
probably dangerous implementation dependency which permits for using
any arbitrary class from the EditorLibrary.

The exact form of the API is still question. It can be set of
specialized classes e.g. HyperlinkProviderManager or some kind of
generic mime type based SPI as proposed above.



Comment 7 Jaroslav Tulach 2005-01-18 13:19:34 UTC
I've seen description of an api in arch*.xml, but without using <api>
tag. Please fix that as well.
Comment 8 Miloslav Metelka 2005-01-18 13:31:37 UTC
Thanks to everyone, I hope that I can understand Hrebejk's opinion as
an agreement with this integration ;)
Yardo, there is an <api> tag used for EditorHyperlinkSPI in the
arch*.xml and I've just double-checked that it is present in the
generated .html file as well.

So I'm going to integrate the change into the trunk.
Comment 9 Miloslav Metelka 2005-01-18 17:10:18 UTC
Integrated into main trunk.

Checking in editor/manifest.mf;
/cvs/editor/manifest.mf,v  <--  manifest.mf
new revision: 1.62; previous revision: 1.61
done
Processing log script arguments...
More commits to come...
Checking in editor/arch/arch-editor.xml;
/cvs/editor/arch/arch-editor.xml,v  <--  arch-editor.xml
new revision: 1.19; previous revision: 1.18
done
Processing log script arguments...
More commits to come...
Checking in editor/lib/manifest.mf;
/cvs/editor/lib/manifest.mf,v  <--  manifest.mf
new revision: 1.5; previous revision: 1.4
done
Processing log script arguments...
More commits to come...
Checking in editor/lib/nbproject/project.xml;
/cvs/editor/lib/nbproject/project.xml,v  <--  project.xml
new revision: 1.2; previous revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in editor/libsrc/org/netbeans/editor/BaseKit.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v  <--  BaseKit.java
new revision: 1.127; previous revision: 1.126
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/DefaultHyperlinkProviderManager.java,v
done
Checking in
editor/libsrc/org/netbeans/lib/editor/hyperlink/DefaultHyperlinkProviderManager.java;
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/DefaultHyperlinkProviderManager.java,v
 <--  DefaultHyperlinkProviderManager.java
initial revision: 1.1
done
RCS file:
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkOperation.java,v
done
Checking in
editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkOperation.java;
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkOperation.java,v
 <--  HyperlinkOperation.java
initial revision: 1.1
done
RCS file:
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkProviderManager.java,v
done
Checking in
editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkProviderManager.java;
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/HyperlinkProviderManager.java,v
 <--  HyperlinkProviderManager.java
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/spi/HyperlinkProvider.java,v
done
Checking in
editor/libsrc/org/netbeans/lib/editor/hyperlink/spi/HyperlinkProvider.java;
/cvs/editor/libsrc/org/netbeans/lib/editor/hyperlink/spi/HyperlinkProvider.java,v
 <--  HyperlinkProvider.javainitial revision: 1.1
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/editor/src/META-INF/services/org.netbeans.lib.editor.hyperlink.HyperlinkProviderManager,v
done
Checking in
editor/src/META-INF/services/org.netbeans.lib.editor.hyperlink.HyperlinkProviderManager;
/cvs/editor/src/META-INF/services/org.netbeans.lib.editor.hyperlink.HyperlinkProviderManager,v
 <--  org.netbeans.lib.editor.hyperlink.HyperlinkProviderManager
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in editor/src/org/netbeans/modules/editor/EditorModule.java;
/cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v  <-- 
EditorModule.java
new revision: 1.114; previous revision: 1.113
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/editor/src/org/netbeans/modules/editor/hyperlink/LayerHyperlinkProviderManager.java,v
done
Checking in
editor/src/org/netbeans/modules/editor/hyperlink/LayerHyperlinkProviderManager.java;
/cvs/editor/src/org/netbeans/modules/editor/hyperlink/LayerHyperlinkProviderManager.java,v
 <--  LayerHyperlinkProviderManager.java
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in ide/golden/impl-deps.txt;
/cvs/ide/golden/impl-deps.txt,v  <--  impl-deps.txt
new revision: 1.11; previous revision: 1.10
done
Checking in ide/golden/public-packages.txt;
/cvs/ide/golden/public-packages.txt,v  <--  public-packages.txt
new revision: 1.12; previous revision: 1.11
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/java/editor/src/org/netbeans/modules/java/editor/hyperlink/JavaHyperlinkProvider.java,v
done
Checking in
java/editor/src/org/netbeans/modules/java/editor/hyperlink/JavaHyperlinkProvider.java;
/cvs/java/editor/src/org/netbeans/modules/java/editor/hyperlink/JavaHyperlinkProvider.java,v
 <--  JavaHyperlinkProvider.java
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in
java/editor/src/org/netbeans/modules/java/editor/resources/layer.xml;
/cvs/java/editor/src/org/netbeans/modules/java/editor/resources/layer.xml,v
 <--  layer.xml
new revision: 1.3; previous revision: 1.2
done
Processing log script arguments...
Mailing the commit message to cvs@java.netbeans.org,
cvs@ide.netbeans.org, cvs@editor.netbeans.org (from mmetelka@netbeans.org)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo