This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | check-javahelp doesn't detect broken links in object tags | ||
|---|---|---|---|
| Product: | platform | Reporter: | Patrick Keegan <pkeegan> |
| Component: | Help System | Assignee: | Jaroslav Havlin <jhavlin> |
| Status: | STARTED --- | ||
| Severity: | blocker | CC: | tgiunipero |
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://wiki.netbeans.org/JavaHelp_CheckHelpSets | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Attachments: | Proposed patch | ||
moving opened issues from TM <= 6.1 to TM=Dev Reassigning to the new "core/help system" owner obarbashov. Moving JH issues to Victor. 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
Created attachment 81294 [details]
Proposed patch
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 [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.) [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. |
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>