TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
RE: API/javadoc - classes/methods that should not be public
Subject:RE: API/javadoc - classes/methods that should not be public From:"Bradbury, Geoffrey (RSA, Brisbane)" <GBradbury -at- rsasecurity -dot- com -dot- au> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 23 Apr 2001 08:06:10 +1000
Greetings David...
I'm just getting in to documenting Java material. Sounds like an issue I'm
likely to encounter in the future. One possibility is to import the Javadoc
HTML pages into FrontPage, delete the non-public public class description
pages, then use FrontPage's link verification tool to search and destroy
broken links to those now-deleted pages. The other, perhaps easier, option
is to replace those same pages with a generic page with a description, "This
method/class not publicly accessible. This page is for completeness.", or
words to that effect. I'd don't like your solution 1: rot link is so easy to
avoid (with a little attention). It can make an otherwise great product look
dodgy.
-----Original Message-----
From: David Price [mailto:price -at- ontos -dot- com]
Sent: Saturday, 21 April 2001 6:52
To: TECHWR-L
Subject: API/javadoc - classes/methods that should not be public
Doing a little poll here, trying to figure out which way to go. I'm
documenting an API using javadoc, importing it into HTML Help as the
reference piece of a Programmer's Guide. There are a number of classes &
methods declared public that should not really be public (utility classes,
etc.). These classes/methods are "undocumented," meaning there may or may
not be comments in there, and they may or may not make sense. There is no
option in javadoc (yet) to exclude these. I see two options:
1. Import the whole thing, let the chips fall where they may. Advantage:
structural completeness, no broken links. Disadvantage: some garbage, some
empty classes/methods. I'm not linking directly to any of these methods
from within the main doc, so someone might stumble across them only if they
start following links within the meat of the API doc.
2. Remove the html files for those classes that shouldn't be public before
importing in HTML Help. Advantage: everything has been looked at, reviewed,
etc., and is reasonably accurate. Disadvantage: broken links.
Anybody else run into this issue? Do you have any better solutions?
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27. http://www.pdfconference.com.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
