Bug 117506 - check-javahelp doesn't detect broken links in object tags
check-javahelp doesn't detect broken links in object tags
Status: STARTED
Product: platform
Classification: Unclassified
Component: Help System
6.x
All All
: P3 (vote)
: 6.x
Assigned To: Jaroslav Havlin
issues@platform
http://wiki.netbeans.org/JavaHelp_Che...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-02 18:23 UTC by Patrick Keegan
Modified: 2011-09-01 16:04 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (42.92 KB, patch)
2009-04-30 11:20 UTC, Victor Vasilyev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Keegan 2007-10-02 18:23:16 UTC
If there is a broken link in an object tag in a help topic, the link check doesn't detect it, e.g. nothing would be
reported on this: 

<object classid="java:com.sun.java.help.impl.JHSecondaryViewer">
    <param name="content" value="../project/csh/BOGUSFILENAME.html">
    <param name="viewerActivator" value="javax.help.LinkLabel">
    <param name="viewerStyle" value="javax.help.Popup">
    <param name="viewerSize" value="400,160">
    <param name="text" value="free-form projects">
  </object>
Comment 1 Lukas Hasik 2008-04-10 21:23:05 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 2 Antonin Nebuzelsky 2008-11-14 15:17:33 UTC
Reassigning to the new "core/help system" owner obarbashov.
Comment 3 Alexei Mokeev 2009-03-05 13:57:32 UTC
Moving JH issues to Victor.
Comment 4 Victor Vasilyev 2009-04-23 23:32:20 UTC
There is another class of the objects that is widely used in the NetBeans JavaHelp sets.
It is "java:org.netbeans.modules.javahelp.BrowserDisplayer". For example:

<object CLASSID="java:org.netbeans.modules.javahelp.BrowserDisplayer">
    <param name="content" value="http://bits.netbeans.org/dev/javadoc/">
    <param name="text" value="<html><u>NetBeans API Javadoc</u></html>">
    <param name="textFontSize" value="medium">
    <param name="textColor" value="blue">
</object>

In both examples the URL is represented as a value of the object property with the name "content",
but we must not rely on it as on the common case for finding property values that are needed be checked!
The JavaHelp 2.0 Specification says in the section "B.3 Java Components in <OBJECT> Tag":
"...
The reference implementation supports a powerful <OBJECT> tag. In the reference implementation
the CLASSID that denotes the class name is used to instantiate the class.
The result is expected to be a lightweight AWT Component. This class is interpreted
as a JavaBeans component --the <PARAM> tag associated with the <OBJECT> tag is used
to provide NAME/VALUE pairs. Each NAME is interpreted as the name of a String property
of the JavaBeans component and the value is assigned to it.
..."

Issue Environment
-----------------

1. Any JavaBeans component with a set of the string properties can be specified as a class in the <OBJECT> tag.

2. There is no way to recognize String property/properties of the class that contain URL. E.g. there are no any
agreements about the property naming for these JavaBeans components, nor possibility to explicitly specify a real type
of the property value represented as a String.

3. We can't change the JavaHelp specification. Just as we must take into account that 1100+ occurrences of the <OBJECT>
tags exist in Help Sets located only in main repository for the NetBeans 6.7, and also, there is uncountable number of
users Help Sets where the tag <object> is used according to the specification.

4. The NetBeans code base already contains two the Help Set Checkers as a response to the Issue #13931.
Both the checkers extend org.apache.tools.ant.Task:
- Development time checker (Ant task <checkhelpsets>)
http://hg.netbeans.org/main/file/d029f73eba5c/nbbuild/antsrc/org/netbeans/nbbuild/CheckHelpSets.java
- Run time checker (Ant task <checkhelpsetsbin>)
http://hg.netbeans.org/main/file/d029f73eba5c/nbbuild/antsrc/org/netbeans/nbbuild/CheckHelpSetsBin.java
Both the checkers rely on the static method scan(...15 arguments, only 10 are documented!...) with recursion to test the
hyperlinks in the HTML tags like <a> and <img>.
See http://hg.netbeans.org/main/file/fd73f346cdd1/nbbuild/antsrc/org/netbeans/nbbuild/CheckLinks.java

It seems the issue is not a defect, but a separate feature.
Proposal to fixing the issue is here: http://wiki.netbeans.org/JavaHelp_CheckHelpSets
Comment 5 Victor Vasilyev 2009-04-30 11:20:48 UTC
Created attachment 81294 [details]
Proposed patch
Comment 6 Victor Vasilyev 2009-04-30 12:41:42 UTC
The proposed patch provides ability for a JavaHelpSet writer to check the well-known <object> elements and the URIs
values presented in the nested <param  name="content" ...> elements.

Details about current implementation is here
http://wiki.netbeans.org/JavaHelp_CheckHelpSets#section-JavaHelp_CheckHelpSets-HTMLObjectElementsCheckerVersion1.0
 
Comment 7 Jesse Glick 2009-05-01 15:37:16 UTC
[JG01] You will commit to core-main repo I guess?


[JG02] Moving link checking classes to a subpackage sounds like a good idea. BTW use

[diff]
git=1

so that your patches correctly represent renames. Also see if you haven't:

http://wiki.netbeans.org/HgHowTos#section-HgHowTos-DevelopAPIReviewPatchesUsingMQ


[JG03] I don't see any reason to disable the check of <object> tags by default in 6.7. If your patch seems to work, use it.


[JG04] Since there are only two knows <object> types that need to be checked, you can probably just hardcode them in the
task now, rather than try to pass them in as Ant properties. There is no realistic expectation that we will need to
expand the list later.


[JG05] "All broken URLs should be shown as the warnings (not errors!) in the Ant log. The build should not be stopped if
a broken URL has been found." - not sure if and how this differs from the current behavior, but just ensure that broken
links in <object> are treated the same way as broken links in <a> or JH map files are already.


[JG06] Consider using javax.swing.text.html for parsing.


[JG07] Additions to CheckLinksTest.java would be valuable, better than the commented-out main method.

(And of course try the link checker on real examples among our JH help sets to look for unexpected corner cases.)
Comment 8 Victor Vasilyev 2009-05-20 15:08:21 UTC
[JG01] You will commit to core-main repo I guess?
[VVG01] OK

[JG02] Moving link checking classes to a subpackage sounds like a good idea.
[VVG02]OK I will move 
org.netbeans.nbbuild.CheckHelpSets
org.netbeans.nbbuild.CheckHelpSetsBin
org.netbeans.nbbuild.CheckLinks
and new class HTMLObjectElementsChecker
to the new sub package org.netbeans.nbbuild.doc

Note, the package name org.netbeans.nbbuild.helpsets previously proposed by me is inconsequent due to the CheckLinks
that is also used to check the JavaDoc files. 

[JG03] I don't see any reason to disable the check of <object> tags by default in 6.7. If your patch seems to work, use it.
[VVG03] I agree. The requirements have changed on the wiki page. The proposed implementation already has such behavior. 


[JG04] Since there are only two knows <object> types that need to be checked, you can probably just hardcode them in the
task now, rather than try to pass them in as Ant properties. There is no realistic expectation that we will need to
expand the list later.
[VVG04] I agree. The proposed implementation already has such behavior.


[JG05] "All broken URLs should be shown as the warnings (not errors!) in the Ant log. The build should not be stopped if
a broken URL has been found." - not sure if and how this differs from the current behavior, but just ensure that broken
links in <object> are treated the same way as broken links in <a> or JH map files are already.
[VVG05] The proposed implementation does not change behavior of the Ant tasks. 


[JG06] Consider using javax.swing.text.html for parsing.
[VVG06] Potentially, I agree, but the implemented parser has been designed to have correct results on unstable code. 
I am not sure about the javax.swing.text.html parser.

Before replacing the parser, we need have a collection of the unit tests to be sure that the javax.swing.text.html
parser is applicable for the checker. The tests should cover the valuable use cases against parsing of unstable HTML code.

[JG07] Additions to CheckLinksTest.java would be valuable, better than the commented-out main method.
Yes, of course. The main method is the non-removed atavism that was used by me to prepare an usage example in the
JavaDoc comment. It will be removed. 

(And of course try the link checker on real examples among our JH help sets to look for unexpected corner cases.)
Of course, it is a primary use case that was used, and I've already seen some corner cases.


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