[jbosstools-dev] Hyperlinks in Eclipse 3.4

[Victor V. Rubezhny]

> -----Original Message-----
> From: Max Rydahl Andersen [mailto:max.andersen at redhat.com]
> Sent: Thursday, June 05, 2008 10:44 AM
> To: vrubezhny at exadel.com; jbosstools-dev at lists.jboss.org
> Subject: Re: [jbosstools-dev] Hyperlinks in Eclipse 3.4
>
>
> > There is the "org.eclipse.ui.workbench.texteditor.hyperlinkDetectors"
> > extention point declared in previous Eclipse versions (since
> 3.3). But for
> > some reasons we're using it only to declare our
> > SeamELInJavaStringHyperlinkDetector to process hyperlinks for
> Seam ELs in
> > Java-Strings in Java Editor while we're using different way to
> install our
> > detectors to XML/HTML/JSP editors (Java Editor supports this
> extention point
> > and it seems that this is the only way to build-in the Java editor to
> > process the Hyperlinks).
>
> Ok.
>
> > Also there is the
> > "org.eclipse.ui.workbench.texteditor.hyperlinkDetectorTargets" extention
> > point which helps to define the targets (document content
> types) where the
> > declared Hyperlink Detector is to be used for. Here is also
> nothing usefull
> > for us because our Hyperlink detectors mostly depend on
> partition types but
> > not on the content type. There is no partition targeting in
> Eclipse 3.4 (and
> > probably it will never be done).
>
> eh, couldn't you just do the partition targeting from inside your
> content typed
> based document ?
>
Missunderstood your "just do the partition targeting from inside your
content typed based document"

If I understood correctly, you asked if we can install our Hyperlink
detector using the
"org.eclipse.ui.workbench.texteditor.hyperlinkDetectorTargets" extention
point... So, yes it possible.
The main change in functionality would be the Hyperlinks ordering - our
Hyperlink detector will not be invoked first anymore (at least there is no
more guarantee that it could be invoked first) and its Hyperlinks (if any)
will not appear first in the result list. It was important earlier because
of only one Hyperlink was shown as result.
Read next (on "kosher" reply).

> This would enable us to provide hyperlinks for EL or classnames
> in any XML...
>

Yes, I think it woud. But for now the overloaded SourceViewerConfiguration
is used for any XML editor, so our Hyperlink detector is to be invoked too.
But not all the XMLs are Struts/Jsf meaningfull. Most part of Hyperlinks are
struts/jsf dependent, so they aren't play in "any" XMLs. They play only for
"known" XMLs. Any way we should know the entity of some node/attribute in
xml first before we could provide some hyperlink for its value.

> There is of course the challenge of avoiding duplicates with
> existing hyperlinks
> detectors, but if we have a good preference page for controlling
> what choices we
> will make available it should be ok.
>
> > There is nothing new in Eclipse 3.4 except the multiple
> Hyperlinks are shown
> > when more than one possibility is found. Probably some editors
> aren't using
> > this new possibility, but XML editor does.
>
> Yes, I like that.
>
> > Since the multiple choices are shown for the Hyperlinks in
> Eclipse 3.4 (but
> > not only the first Hyperlink found is shown) we could modify
> our hyperlink
> > detectors installation way to make it kosher.
>
> Not sure what you mean by that last part ?

I meant "to make it built in common way" using described extention points
instead of overriding the SourceViewerConfiguration to install our Hyperlink
Detector.

There may be some additional problems in doing this because we've made it
thru source viewer configuration overriding to guarantee that out Hyperlink
Detector (its Hyperlinks) will be first in the result list (and this will
guarantee that the Hyperlink from our detector will play). This was
important because the only one hyperlink was shown in the editor. If we're
planning to use multiple hyperlink selector possibility than it become less
important for us.

>
> -max

Victor