LinkListener Functionality Should Be Generified [R9 Deferred]

[GoogleCodeExporter]

*** This issue was imported from http://java.net/jira/browse/XHTMLRENDERER-89

It was reported by grlea on 07.06.2005 07:43:42 +0200 and last updated in the 
previous bug tracker on 20.07.2008 17:47:51 +0200

Found in
Operating System: All
Platform: All

The priority for this issue at migration was Critical.

Original description: 
The XHTMLPanel(UserAgentCallback) constructor adds a LinkListener to the panel, 
while the other constructors don't. This makes for inconsistent behaviour 
depending on which constructor is used. I would suggest the listener does not 
add any listeners to itself by default.

If there is a reason why the listener is added in that constructor and that one 
only, then the fact that it is added should be documented in the constructor's 
javadoc:

Instantiates a panel with a custom {@link 
org.xhtmlrenderer.extend.UserAgentCallback} implementation and adds a 
LinkListener to the panel.

Original issue reported on code.google.com by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

[GoogleCodeExporter]

grlea wrote on 10.06.2005 00:19:57 +0200:
Thinking about this some more, from an XR user's perspective, I think the 
LinkListener functionality should be generified so that:

- LinkListener is an interface that has the methods:
     linkEntered(String href)
     linkExited(String href)
     linkClicked(String href)
  [If keyboard navigation is ever supported, the following would also be needed:
     linkFocused(String href)
     linkBlurred(String href)

- There should probably also be a LinkAdapter.

- BasicPanel should have addLinkListener() and removeLinkListener() methods.

- All constructors of BasicPanel should add a (package-visibility?) 
MouseListener to themselves that does the work of interpreting MouseEvents into 
LinkListener calls.

- Three standard LinkListeners should be supplied, but not installed by default 
(I think - not sure on the installation part, actually): 
     HandCursorLinkListener - changes the cursor to a hand on hovering over a 
link;
     InternalDocumentLinkListener - handles links to anchors in the same 
document only;
     DocumentChangeLinkListener - incorporates the functionality of 
InternalDocumentLinkListener and also changes the panel's document if the link 
is to another document.

Separating it out this way would allow XR users to more easily implement things 
like showing the URL being hovered over in a status bar, or only following 
internal links within XR and launching a browse for anything external (i.e. 
jdic.Desktop.browse(url)).

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

[GoogleCodeExporter]

tobega wrote on 26.06.2005 02:34:45 +0200:
DOM Level 2 Events cover all this and more.

Only problem is where and how to put the "extension points". Maybe the suggested
LinkListener interface is good. How to combine a default implementation with
UserAgentCallback? Or NamespaceHandler?

Related problem: form submission.

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

[GoogleCodeExporter]

joshy wrote on 18.07.2005 20:10:56 +0200:
Some of this exists already but needs to be standardized. I'm moving this off 
to R6 though.

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

[GoogleCodeExporter]

pdoubleya wrote on 25.07.2006 15:20:23 +0200:
These are all good ideas, but nothing critical to address for R6; defer to R7.

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

[GoogleCodeExporter]

pdoubleya wrote on 20.07.2008 17:47:51 +0200:
Deferring to R9, requires some re-think of link listener support do do this
right. One of those issues we should also look to the upcoming "web browser"
component in JDK 6 u10 for inspiration on.

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47