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.

I'd appreciate you posting your solution.

...cheers!

----------------------------------
Geoff Bradbury
Technical Writer
RSA Security Australia Pty Ltd
Tel: +61 7 3227 4470
Mob: 0419 626 758
Fax: +61 7 3227 4400
email: gbradbury -at- rsasecurity -dot- com -dot- au

-----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?

- David

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** 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.


Previous by Author: Re: "install" as a noun?
Next by Author: Automated Revision Notification
Previous by Thread: Re: API/javadoc - classes/methods that should not be public
Next by Thread: Gender Issues in Tech Communication


What this post helpful? Share it with friends and colleagues:


Sponsored Ads