
![]() |
Show Changes |
![]() |
Edit |
![]() |
|
![]() |
Recent Changes |
![]() |
Subscriptions |
![]() |
Lost and Found |
![]() |
Find References |
![]() |
Rename |
![]() |
Administration Page |
| Search |
History
| 5/8/2006 5:27:52 PM |
| -196.25.255.194 |
| 9/30/2005 2:53:57 PM |
| -66.69.144.142 |
| 9/29/2005 8:38:57 AM |
| -12.126.209.202 |
| 9/29/2005 8:38:02 AM |
| -12.126.209.202 |
| 3/17/2005 8:01:49 AM |
| CraigAndera-206.67.217.15 |
![]() |
List all versions |
This page represents information about version 0.3 of FwDocGen, the first publically available version of FwDocGen.
Get it from the FwContrib workspace on SourceForge.
And you can get there by clicking here
Part of the FwContrib workspace on SourceForge.
I'm aware of the major overlap this tool has with WikiClassPages. To explain, here is part of an email conversation between me and RyanLaNeve:
One of the things that I find most useful about FlexWiki is its ability to email me a WikiNewsletter that highlights the changes that have been made recently. I don't know if you saw, but I made this a fair amount more powerful by adding the capability to specify a wildcard in the topic list, as well as the ability to exclude certain pages.
Our plan is to generate documentation for our classes from the XML doc files that the C# compiler generates. I don't particularly care about how we do this, and your behavior would be a great option...except for the fact that it won't give us diffs. FlexWiki operates by comparing the WikiText in the page itself...which is always the same if we use your WikiBehavior.
The alternative that I've come up with is - as part of our build process - to use FwSync to download all the exisiting documentation, overwrite the docs with docs generated from the new build, and then to upload the changed files (FwSync will compare the "before" and "after" files, and only upload those that have actually changed). There are some intricacies around how to name the pages, but that's the basic idea.
The basic idea is to use C# XMLDoc comments to emit an XML file describing the classes and interfaces in the build. Then we'd validate them against a schema to ensure that required extra elements are present, transform them to WikiText, and upload them to the wiki site via the editing web service.
The major goals of this effort are:
Non-goals of this effort are:
What's the difference between a goal and a non-goal?
The tool runs a series of XSLT-based transforms over the output of the NDoc XML documenter. These transforms will create a series of .wiki pages that will have names like:
and so on. The first part of the name identifies what sort of documentation page it is, and the last bit is a "uniquifier". While it would be nice for linking purposes to be able to use the name of the class or the namespace as the name of the page, this has the problem that the period is interpreted specially by FlexWiki. Plus, unqualified class names are not unique, and qualified class names like "Big.Long.Complicated.Namespace.Classname, Big.Long.Complicated.Assembly.name" are really long, and therefore not particularly useful as a linking mechanism.
The uniquifier at the end will be generated based on a hash of the fully qualified name of the thing we're documenting (class, namespace, method, etc.). By using a hash like this, we can guarantee that the page will always have the same name across different builds of the documentation.
FwDocGen operates on the output of the NDoc tool, which is available at http://ndoc.sourceforge.net . You must select "XML" as the NDoc output mode.
The reason for using NDoc is that is performs a lot of useful pre-processing that FwDocGen would have had to re-implement. Since it is itself freeware, it doesn't seem an unreasonable burden to require it.
The way I see this working in a build is as follows:
This should result in a WikiNewsletter with that includes diffs of only the files that have changed.
There is basic support for each page to include a link to a comments page that will appear in a different namespace. Putting it in a different namespace makes it easier to whip through and obsolete all the actual documentation pages. The { { link } } syntax should make it easy to actually includes the contents of the comment page on the documentation page.
If you simply type
fwdocgen
from the command line, you will get a message telling you how to use FwDocGen. Here is what it says:
fwdocgen Version 0.3.1722.5808 Copyright (c) 2004 Craig Andera candera@develop.com
Error: /docdir argument is required when /writeonly is not specified
fwdocgen /docdir <docdir> /docns <docns> /commentdir <commentdir>
/commentns <commentns> [ /generator <generator> ] [ /verbose ] <input>
fwdocgen /writeonly [ /templatedir <templatedir> ]
/docdir Specifies the directory to which to output documentation files
/docns Specifies the FlexWiki namespace to use for doc files
/commentdir Specifies the directory to which to output comments files
/commentns Specifies the FlexWiki namespace to use for comment files.
/generator Optional. If present, specifies the XSLT that will be run
to generate the script that will drive the generation process.
If not present, the default transform is used.
/verbose Print extra debugging information to the console. Note: this
produces a *lot* of extra info.
/writeonly Specifies that rather than generating documentation, the
program should dump the default set of XSLT templates to
the <templatedir> (if specified) or the current directory
(if templatedir is not specified). If this parameter is
specified, all other parameters are optional.
/templatedir Optional. If not specified, the current directory will be used.
<input> An ndoc-generated XML file containing the classes, namespaces,
methods, etc. for which you are generation documentation.
Not required when /writeonly is specified.
<generator> The relative or absolute path to the XSLT that will be run
against the input document to create the script that will
drive the generation process
Note that you must either specify the /writeonly switch or all of the /docdir, /docns, /commentdir, and /commentns switches. The /templatedir and /generator switches are optional.
FwDocGen operates in one of two modes. When the /writeonly switch is not present, it generates wiki documentation pages. When the /writeonly switch is present, it merely spits out the default XSLT template it uses to generate documentation. The idea is for these to provide a useful starting point for custom transforms, which can be specified using the /generator option (see "Providing Custom Templates" below).
FwDocGen provides a built-in transforms for generating a reasonable set of documentation pages. (Well, reasonable in that it works - the output itself sucks pretty bad right now. The default template will be improved in future releases.) This template can be written out to disk using the /writeonly switch. It can then be modified and used to generate new documentation. Simply specify the template you'd like to use with the /generator parameter when you generate documentation with FwDocGen.
None yet. At some point I'd like to run FwDocGen over the FlexWiki assemblies and post the resulting pages on this wiki somewhere.
Bugs and feature requests can be logged here or at the FwContrib project page .