As far as I know, there isn't a way another way. Doxygen doesn't recognize JavaScript. I also do not know of any tool that works with JavaScript to create documentation. Its a pain to set it up, but once it gets going, its easy to maintain.
Rob On 11/16/2001, Laszlo Teglas wrote: > Does this mean we have to have a set of dummy java classes to mirror our > dynAPI? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert > Rainwater > Sent: November 16, 2001 11:16 AM > To: [EMAIL PROTECTED] > Subject: Re[4]: [Dynapi-Dev] Documentation Project > Of course it recognizes constructors, public, private methods , etc. > Doxygen is designed for c++ and java. To create the docs, I just > wrote dummy java classes to represent the dynlayer, etc. > Robert > On 11/16/2001, Laszlo Teglas wrote: >> Will it recognize constructors, public methods, public attributes, private >> methods, private attributes. Or will we just settle on documenting > Functions >> and Variables? >> Decision time! >> And remember Even if we use Doxygen, this will only produce the reference >> part of the documentatiion. We will still have to do the intro, examples, >> and tutorial sections by hand. >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Fair >> Sent: November 16, 2001 10:42 AM >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED] >> Subject: Re: Re[2]: [Dynapi-Dev] Documentation Project >> I agree that Doxygen is the way to go for documentation on DynAPI. >> Matt >> On Fri, 2001-11-16 at 09:38, Robert Rainwater wrote: >>> Like I said before, all of this could be automated using doxygen. >>> Here's an old version of dynlayer in cvs that was used to create the >>> dynlayer docs: >>> >>> >> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/dynapi/dynapi/docs >> /config/data/dynapi/api/Attic/dynlayer.js?rev=HEAD&content-type=text/plain >>> >>> Here's the website for doxygen: >>> http://www.doxygen.org/ >>> >>> It will probaly be too much to build our own system, when one is >>> already available. It also creates latex, pdf, rtf and unix man pages >>> from the same source. >>> >>> Robert >>> >>> On 11/16/2001, Laszlo Teglas wrote: >>> > I agree. The content should be on separate XHTML pages. Whether it's >>> > automatically generated from the src comments or manually cut and > pasted >> in >>> > the beginning. I'm not so keen on storing the data in some js var. as >>> > suggested: >>> >>> > var Data = { >>> > Feature:"DynLayer", >>> > Description:"Dynamic Layer Manipulation", >>> > Details:"The dynLayer library. . .", >>> > Example:"http://www.richardinfo.com/examples/php/examples.html";, >>> > SubData: >>> >>> >>> > -----Original Message----- >>> > From: [EMAIL PROTECTED] >>> > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard >> Bennett >>> > Sent: November 15, 2001 7:02 PM >>> > To: Laszlo Teglas; [EMAIL PROTECTED] >>> > Subject: Re: [Dynapi-Dev] Documentation Project >>> >>> >>> > Our content should simply be on separate XHTML pages, which can then >>> > either be loaded into a frame-set, or into a dynapi page using >> loadpanel. >>> >>> > ----- Original Message ----- >>> > From: Laszlo Teglas >>> > To: [EMAIL PROTECTED] >>> > Sent: Thursday, November 15, 2001 11:12 PM >>> > Subject: RE: [Dynapi-Dev] Documentation Project >>> >>> >>> > I like the idea. >>> > Lets look at the requirements: >>> > 1) One XHTML file that displays the widget (No problem) >>> > 2) One DynAPI widget that displays the data (Little coding and >>> > debugging, No problem) >>> > 3) One massive data file (Or many smaller data files) - This >> implies >>> > the following: >>> > a) we can't use a database because we need a server side >> scripting >>> > engine to extract the data. this can't be done because we want the docs >> to >>> > be available offline locally independent of a server >>> > b) we can't really use a massive data file either think of > the >>> > consequences: accessing the page online for the first time with a >> standard >>> > modem would require many minutes, maybe tens of minutes. Think about > all >> the >>> > intro module docs, all the reference docs, all the example docs, and > the >>> > tutorial docs, being downloaded all at once whether you want it or not. >> Just >>> > not an option. >>> > c) using many smaller data files may be viable if we can >> figure >>> > out how to make the widget access the required files on demand. I'm not >> sure >>> > how this would be done. Any Ideas? >>> >>> > -----Original Message----- >>> > From: [EMAIL PROTECTED] >>> > [mailto:[EMAIL PROTECTED]]On Behalf Of >> Strolia-Davis >>> > Christopher Contr MSG MAM >>> > Sent: November 15, 2001 4:24 PM >>> > To: 'Laszlo Teglas'; [EMAIL PROTECTED] >>> > Subject: RE: [Dynapi-Dev] Documentation Project >>> >>> >>> > You could just have all the information in a data file, and create > a >>> > widget in DynApi to display it. >>> >>> > That would kill three birds with one stone >>> > 1. help file can be updated quickly and easily without modifying >> much >>> > html or code >>> > 2. Data is separate from markup, and can be easily transformed at a >>> > later date >>> > 3. You can show off the DynApi >>> >>> >>> > -----Original Message----- >>> > From: Laszlo Teglas [mailto:[EMAIL PROTECTED]] >>> > Sent: Thursday, November 15, 2001 11:46 AM >>> > To: [EMAIL PROTECTED] >>> > Subject: RE: [Dynapi-Dev] Documentation Project >>> >>> >>> > Even with Layers, you will still need to update every file, every >> time >>> > the navsys changes. >>> > -----Original Message----- >>> > From: [EMAIL PROTECTED] >>> > [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Melvin >>> > Sent: November 15, 2001 9:24 AM >>> > To: Laszlo Teglas; [EMAIL PROTECTED] >>> > Subject: Re: [Dynapi-Dev] Documentation Project >>> >>> >>> > frames? FRAMES?! >>> > Um, this a DHTML library, why not use Layers..? >>> > ----- Original Message ----- >>> > From: Laszlo Teglas >>> > To: [EMAIL PROTECTED] >>> > Sent: Wednesday, November 14, 2001 5:29 PM >>> > Subject: RE: [Dynapi-Dev] Documentation Project >>> >>> >>> > php / asp / cgi / jsp / cfm / perl >>> >>> > these all require server side engines. Thus they can not be >> viewed >>> > from anywhere. They can only be viewed when served up by a server. I >> have >>> > mentioned in my earlier comment, that "We want the document to be >> viewable >>> > offline locally, therefore we can't use any server side script to >> include >>> > the navigation system." >>> >>> > I believe this is one of the reasons why Sun uses frames for >> it's >>> > extensive documentations of the Java API: >>> > http://java.sun..com/j2se/1.4/docs/api/index.html >>> >>> > NanoFace =;^) >>> > -----Original Message----- >>> > From: [EMAIL PROTECTED] >>> > [mailto:[EMAIL PROTECTED]]On Behalf Of Michael >>> > Pemberton >>> > Sent: November 14, 2001 4:48 PM >>> > To: [EMAIL PROTECTED] >>> > Subject: RE: [Dynapi-Dev] Documentation Project >>> >>> >>> > >I vote for Frames =;^) >>> >>> > >Using frames may also help when we want to update > different >>> > formats of the >>> > >documentation. i.e. pdf files can be set up to list the >> content >>> > files >>> > >consecutively without the need to strip out the navsys > from >>> > every page. We >>> > >could then replicate the navsys as a table of contents. (I >>> > haven't actually >>> > >tried this, I'm just thinking out loud) I don't know much >> about >>> > Win2PDF. >>> > >Does it take a graphical snap shot, or does it copy the >> text of >>> > the document >>> > >and format it into pdf? If it copies the text, does it >> ignore >>> > HTML tags? >>> > >What would it do to a navsys that is made up of tags mixed >> with >>> > content? >>> >>> > This is not really needed. It is quite possible, using php >> / >>> > asp / cgi to include the common navigation code automatically. This >> means >>> > that if written in a specific way, it is then possible to override the >>> > inclusion of such code. This would allow for easy conversion by simply >>> > stripping the "include" calls made in the content files. >>> >>> >>> > -------------------------------------------------------------------- >>> > Get your FREE download of MSN Explorer at >>> > http://explorer.msn.com >>> > _______________________________________________ Dynapi-Dev >>> > mailing list [EMAIL PROTECTED] >>> > http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ >>> >>> >>> _______________________________________________ >>> Dynapi-Dev mailing list >>> [EMAIL PROTECTED] >>> http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ >> _______________________________________________ >> Dynapi-Dev mailing list >> [EMAIL PROTECTED] >> http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ >> _______________________________________________ >> Dynapi-Dev mailing list >> [EMAIL PROTECTED] >> http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ > _______________________________________________ > Dynapi-Dev mailing list > [EMAIL PROTECTED] > http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
