About DocFlex/Javadoc
- Overview
- How does it work?
- How fast does it work?
- Benefits to the users
- Future Versions
1. Overview
DocFlex/Javadoc is both a multi-format
Javadoc Doclet
and a rapid doclet development tool,
which allows easy creation of professional quality Java API documentation
generated by
Javadoc in various output formats.
Key Features
-
Full support of new Java 5.0 language features:
- Generic Types
- Enums
- Annotations
-
Simultaneous support of Java 1.4 and Java 5 (see below).
-
The standard template set
included in the software allows instant generation of
- Framed HTML JavaDoc similar to that generated by the standard Javadoc doclet.
- The same documentation packed into a single HTML file.
-
The exceptional quality
RTF JavaDoc
with the correct rendering of HTML tags embedded in Java comments
(including insertion of images specified with
<img> tags).
Besides this, it is possible to
exclude
from the result documentation any mentioning of classes, fields and methods marked with
the specified tags
or annotations
-- a unique capability unknown to us to be supported
by any other doclet (including the standard one).
-
A high quality graphic Template Designer
allows visual designing of most of things which development is possible otherwise
only by direct Java coding.
-
The Template Designer represents the whole
Doclet API
in the form similar to XML DOM, which is a kind
of a virtual XML document called Doclet Data Source Model (or Doclet DSM).
This makes possible programming and processing of the data provided by the Doclet API using universal
approaches developed for XML (such as
XPath).
-
The templates created with the Template Designer are interpreted by the
DocFlex Doclet, an output generator
implemented as a
Javadoc doclet
and included in the package. In effect, the templates interpreted
by the DocFlex Doclet behave as if they are separate doclets themselves.
You can freely distribute the templates created by you to anyone else and execute them with the
“DocFlex/Doclet”, which is a freeware edition of DocFlex/Javadoc
that includes only the DocFlex Doclet (plus the standard templates) without the
Template Designer.
-
Besides the possibility to specify all doclet setting using
options
on the Javadoc command line, DocFlex Doclet also provides a high quality
Doclet GUI, where you can assign the same settings at once
in a lot more user-friendly way, start the generation, track its progress and cancel it
at any moment (if you wish).
Once the generation has been finished (or cancelled), you can start it again
with different settings and a new (or modified) template set.
This, in effect, allows changing your doclet on the fly.
You won't need to restart the whole Javadoc. All the memory representation
of your Java project provided via the
Doclet API
will remain the same.
This unique capability makes possible extremely fast designing and modification of your templates.
Just change something in the Template Designer, restart the generator
and you can see how it looks now in the result output!
-
The current version of DocFlex Doclet
generates output in the following formats:
HTML (version 4.0)
RTF (version 1.6 - supported since Word 2000)
TXT (plain text)
The plain text output may be particularly useful for various utilizations of Java code information
provided by the Doclet API (for instance, to generate XML files by it, or
SQL files to import into a database).
-
DocFlex/Javadoc supports numerous sophisticated
formatting techniques
which include
- text formatting: fonts, colors, borders
- paragraph formatting: margins, pagination control, borders, colors
- border formatting: styles (solid, double, dashed, dotted), thickness, colors
- tables: arbitrary cell layouts, borders, nested tables
- lists: bulleted, numbered, delimited
- document fields (RTF): page number, number of pages, TOC, etc.
- page formatting: size, orientation, margins, headers/footers
- formatting styles
-
rendering of embedded HTML, which means interpreting in non-HTML output formats (such as RTF)
the HTML tags embedded in Java source comments. Almost all HTML tags practically usable
in doc-comments are supported now. See
Formatting Features | Rendering of embedded HTML
for all supported HTML tags list.
-
The templates can be designed independently on a particular output format, which is selected only
when starting the generation. All formatting specified in templates is defined in some universal way
(using properties
of template components)
and, then, rendered with the suitable features available in the selected output format.
-
Depending on a particular template, the
generated output can be
- single-file document (all formats)
- framed multi-file documentation (HTML only)
-
The framed documentation is generated using special
frameset templates.
Each frameset template, among other things, contain
a frameset definition
that allows defining your own layout of frame windows and target
the documents loaded by hyperlinks into particular frames.
-
DocFlex/Javadoc is able to generate a common network of
hyperlinks
for the whole documentation. The generation of hyperlinks is programmed using special source-
and target-keys defined in the
template components.
It is also possible to program loading several frame windows from a single hyperlink at once.
The hyperlinks can be generated in all output formats that support them (currently, this includes HTML and RTF).
-
Since all content and formatting of the generated documentation now is specified in templates,
the most of options previously used to control behavior of an ordinary doclet now simply become
template parameters.
DocFlex/Javadoc provides elaborated support for template parameters.
The parameters can be defined and
accessed within templates to adjust
the dynamic properties
of template components.
The values of template parameters can be specified both on the Javadoc command line and
interactively using
Parameter Inspector
dialog invoked from the Doclet GUI
provided by the DocFlex Doclet.
System Requirements
DocFlex/Javadoc requires the Javadoc Tool delivered with one of the following
Java Development Kits:
(JDK 6 may be preferable as it works considerably faster.)
Since DocFlex/Javadoc is a pure Java application
(the Template Designer GUI is based entirely on Swing),
it is supposed to work on any operating system with the installed JDK.
Specifically, the software available for downloads
includes both MS Windows BAT files and Linux shell script files
to run DocFlex/Javadoc immediately on those operating systems.
(We have been also reported that DocFlex/Javadoc was successfully working under Mac OS X).
Additionally, a sample Ant buildfile is provided to demonstrate integration of DocFlex Doclet
with the Apache Ant.
For further details, please see product README files on the downloads page.
Simultaneous Support of Java 1.4 and Java 5
As you perhaps know, since JDK 5.0, the
Doclet API
has been extended to reflect the new language features introduced in Java 5.
Because of this, a doclet developed for Java 5 won't work under Java 1.4
(otherwise is possible, of course).
However, as we found (after the preliminary v1.5 beta release), Java 1.4 appears to be still well in use.
So, we have finally decided in DocFlex/Javadoc v1.5.x to support both Java versions (i.e. the new
Doclet API 1.5
and the old
Doclet API 1.4).
Since the binaries compiled for Java 5 are not compatible with Java 1.4, now, DocFlex/Javadoc v1.5.x
(both editions) includes two Java libraries: the one compiled for Java 5+ and another one
compiled for Java 1.4.
The Doclet DSM, on which any DocFlex/Javadoc
templates are based, is always the same.
That is, the Java 5 functionality (i.e. the mapping of entire
Doclet API 1.5
on a virtual XML document model) is present in both libraries.
However, in the version compiled for Java 1.4, everything concerned Java 5 is emulated
by the Doclet DSM Driver itself.
It happened to be very simple to implement. So, we've done this!
As a result, any templates
designed for either Java version will work fine under both Java 5+ and Java 1.4 as well.
The templates simply won't "notice" the difference!
XML Generation
Since XML files are just text files, you can easily generate any sorts of XML output
from the data provided by
Doclet API
using DocFlex/Javadoc.
To generated XML, all you need is to design a template where the output produced
by Data Controls
(from the data obtained from Doclet API) is interchanged with the static text representing certain XML tags,
which can be produced, for instance, by
Label Controls.
Then, you can simply generate a TXT output with such a template, and this will be XML.
Since generating XML is a very general topic (first, you need to choose what a specification that
XML should follow), we have not found yet any particular application where an XML generated with Javadoc
would be of mass interest (except XSL-FO, which is a special case). Therefore, we do not provide any
templates specifically designed to generated XML.
However, if you could suggest such an application, just let us know by sending a e-mail to:
support@docflex.com.
If your idea fits a certain known XML standard, we could quickly design templates
for that application and supplement with them the provided
standard templates
as well as the freeware edition -- DocFlex/Doclet.
2. How does it work?
Here is a UML
implementation diagram, which depicts the functional structure of DocFlex/Javadoc:
The DocFlex/Javadoc implementation consists of four major components:
-
The Doclet DSM Driver, which represents a bridge between Javadoc
Doclet API
and DocFlex core. The driver connects to Javadoc
using Doclet API and supplies data via DSM (Data Source Model) interface that is
a representation of Javadoc data source in the form understandable for DocFlex core. This representation is
called Doclet DSM. The driver also supports
DSM Type interface which provides the data structure and type information about
this data source. The DSM interface is used by DocFlex Generator to obtain data it operates. The DSM Type
interface is used both by the generator to know how to handle those data, and by the Template Designer to provide
data type information during template design.
-
The DocFlex Doclet component, which provides
com.docflex.javadoc.Doclet class
that is the one to be specified with the -doclet option on the Javadoc command line.
The Doclet component handles command line options received from Javadoc, initiates Doclet DSM Driver and starts
the generator. It also may invoke the Doclet GUI,
which provides a user-friendly interface to specify most of parameters and settings used by the generator.
See DocFlex Doclet page for more
information on this topic.
-
The DocFlex Generator, which is launched by DocFlex Doclet and receives from it:
- The Doclet DSM Driver ready to supply data from Javadoc
- The template to be interpreted
- The template parameters and other settings
The generator executes the template and generates the output documentation.
-
The Template Designer, which provides a GUI for designing the templates.
It also starts Doclet DSM Driver (however, without connection to Javadoc) and uses information provided
by DSM Type interface. In the next section, we shall discuss what that information is.
Doclet DSM
When Javadoc
finishes with collecting information from Java sources and then calls a doclet, it provides the doclet
with the information organized in the form rather similar to
XML DOM.
Of course, that information is delivered not via
org.w3c.dom
interface (but via
Doclet API,
instead), and everything goes under different names and notions.
However, one can notice that the structure of that information is very much similar to that described by
DOM.
All data provided by Doclet API can be presented either as some XML elements or as their attributes.
Doclet DSM Driver makes use of this. It maps all
Doclet API classes (such as
com.sun.javadoc.RootDoc,
com.sun.javadoc.ClassDoc
and so on) to the equally named XML elements.
The methods of
Doclet API
classes (or more precisely, the data they return) are mapped according to the following rules:
-
If a method returns one or more objects whose type has an aggregation relationship with the given class
(i.e. the returned objects are part of an object of this class) and, in addition, the method returns all
aggregated objects of such type, then the returned objects are interpreted as children of the XML element
associated with the given class.
For example, class
com.sun.javadoc.ClassDoc
has a method methods(), which returns an array of
com.sun.javadoc.FieldDoc
objects representing all fields of a Java class being documented. Those two classes and method
are mapped as the following:
- Class
com.sun.javadoc.ClassDoc is mapped to XML element ClassDoc
- Class
com.sun.javadoc.FieldDoc is mapped to XML element FieldDoc
-
Method
ClassDoc.fields() is mapped into parent/child relationship between ClassDoc
and FieldDoc elements according to the following XML
DTD declaration:
<!ELEMENT ClassDoc (FieldDoc*)>
-
If a method returns object(s) whose type has an association relationship with the given class,
or in the case of aggregation, the returned array represents only a subset of all aggregated objects
of this type, then this method is mapped as an attribute with
IDREF or IDREFS type
(depending on the cardinality of the returned objects).
For example, method com.sun.javadoc.ClassDoc.interfaces() returns ClassDoc
objects, which represent all interfaces implemented by a documented Java class. Those interfaces are not
part of this class. They exist independently. So, the relationship between the interfaces and the class
implementing them should be interpreted (in our context) as an association. Therefore, the method
ClassDoc.interfaces() is mapped as an attribute interfaces of the ClassDoc XML element.
Here is how this is presented in the form of XML DTD declaration:
<!ATTRLIST ClassDoc interfaces IDREFS>
-
If a method returns a primitive type it is mapped as an attribute of the XML element associated
with the given class. The attribute data type is the same as the one returned by the method.
(Note: DocFlex introduces additional
data types
not presented in XML DTD to handle values of XML elements and attributes suitable for Java-based data sources.)
For example, method com.sun.javadoc.ClassDoc.isAbstract(), which returns a boolean value,
is mapped as isAbstact attribute of the ClassDoc XML element. Here is how this would
looks in the form of XML DTD declaration (if BOOLEAN data type was allowed in DTD):
<!ATTRLIST ClassDoc isAbstract BOOLEAN>
You can see all mapping of
Doclet API
to XML
used by Doclet DSM, if you look at
FlexQuery Assistance Dialog
invoked from the Template Designer (click to enlarge):
In effect, the tree visible on this picture represents all the
Doclet API
in a very simple but equally powerful form.
What are Templates?
The DocFlex/Javadoc templates are actually programs.
The idea behind the template approach is the following.
If you consider how almost any Java library that generates something
(and not only generates -- for instance, powers a GUI system) works,
you will notice that, basically, it may be described as the following:
-
First, we need to create a certain object representation of some controlling structure
(using special classes and methods of that library).
-
Further, we call an interpreter included in that library and pass to it that controlling structure
along with some data source we want to process, e.g. some data file, some interface or whatsoever.
(Actually, such an interpreter may be started just by calling some member method of the root object
representing that controlling structure. For instance, in case of a GUI system, this
may be as simple as
dlg.show()).
-
Finally, the interpreter processes that controlling structure and produces from
the data source some useful output (or shows a GUI).
What the actual programming is all about here, when using such a system, is the first step.
We need to encode the creation of that controlling structure!
(And this may be a piece of work indeed...)
Now, let's imagine that such a controlling structure is serialized to a file
(and, therefore, can be created from it).
What is that file, then? One may call it a “template”!
But if that is a template, why not to create and edit it using some template designer GUI?
That approach has a number of advantages:
-
A designer GUI can visualize everything.
Now, rather than coding abstract method calls, we can visually construct the controlling structure
using the notions of things that we expect to see in the generated output.
-
Since probably every modern document format in its core is based on the same obvious concepts
like flows of text with specified fonts and colors, paragraphs with specified margins, borders and
other properties, tables, bulleted/numbered lists, images and so on, most of such things can
be defined in some universal format-independent way, which can be encoded in the form of template components.
-
Such template components can be visualized in the template designer GUI. This allows easy
manipulation with them (creating/defining, modifying, moving, coping and so on).
Doing the same by calling various Java methods and modifying Java code each time we need
to change something would be a lot more cumbersome!
-
On other hand, the template interpreter will render those template components
with the suitable features of the particular destination output format (such as HTML or RTF).
So, we can be relieved from learning and programming lots of very complicated
(and sometimes poorly documented) things specific to a particular format.
Instead, we can more concentrate on our primary application task.
-
The template designer (to a large degree) ensures that the result controlling structure
(the template) is valid. That is, it won't hang when interpreted and will produce some output anyway.
DocFlex/Javadoc is exactly an implementation of that idea!
The following screenshot shows the
class.tpl
template open in the Template Designer (click to enlarge):
This template is included in the standard template set
and generates the bulk of the documentation.
Standard Template Set
DocFlex/Javadoc includes a ready-to-use template set, which is able to generate an HTML JavaDoc
looking very much similar to that produced by the Standard Javadoc Doclet.
In addition, the same template set can generate unique quality
RTF documentation
(that the standard doclet cannot)!
Another unique feature supported by the standard template set (and not available in the standard Javadoc)
is a possibility to exclude from
the generated documentation the classes, fields and methods marked with special
tags and
annotations.
This gives you incredible flexibility over how you can document your Java project!
Here is an example of the framed HTML documentation generated with the standard template set
(click to see the real HTML):
Everything you see in that documentation has been programmed entirely in the templates!
Currently, the standard template set consists of only 15
template files
(plus one icon), which in total occupy 390 KB.
That is all what was needed to program the entire Java API documentation generator!
In comparison, the recent Java implementation of the Javadoc's standard HTML doclet
(whose Java sources can be found, for instance, at
http://download.java.net/jdk6/
-> jdk-6u2-fcs-src-b05-jrl-22_jun_2007.jar ->
j2se/src/share/classes/com/sun/tools/doclets/) consists of
141 files occupying 979 KB in total.
What's more, unlike the standard doclet's Java sources, all templates provided with
DocFlex/Javadoc are free for any changes and modifications. Using the Template Designer,
you can easily change the look & feel of the generated JavaDoc, insert your company's logotype and so on,
as well as to program eventually whatever you wish
(so much as you are willing to understand how everything works).
Further, you will be free to use your created/modified templates for whatever purpose you need.
For more details about the standard template set please see:
DocFlex/Javadoc | Templates
Doclet GUI
A doclet implemented as
{DocFlex Doclet + template set}
is controlled by lots of settings, which include:
- The main template
- The template parameters
- The output format
- The format-specific options to the output generator
- The output destination (directory/file)
All such settings can be assigned using
options
on the Javadoc command line (most, actually, have their default values).
However, in addition to it, DocFlex Doclet provides a much more user-friendly way
to specify everything.
When no
-nodialog
option has been specified on the command line,
as soon as Javadoc finishes parsing Java sources and calls the doclet to generate the output,
the DocFlex Doclet invokes the following dialog (click to enlarge):
Here, you can fill in all required settings of the DocFlex Doclet:
the template, the output format, the output file/destination.
The additional settings, such as template parameters and the output format options
can be assigned in the special property inspector dialogs invoked by clicking the buttons on the right
(click to enlarge):
The bottom panel in the inspector dialog shows the HTML-preformatted description
of each parameter or format-specific generator option.
When all settings are prepared, you can start the generation by clicking <Run> button.
Then, the generator dialog will transform itself to show the generation progress (click to enlarge):
You can stop the generation at any moment by clicking <Cancel> button.
Once the generation has finished (or cancelled), the generator dialog transforms itself back
into its initial state.
After that, you can change any settings and start the generator again with a new (or modified) template set.
This, in effect, allows changing your doclet on the fly.
At that, you won't need to restart the whole Javadoc.
All the memory representation of your Java project provided via the
Doclet API
will remain the same.
This unique capability makes possible extremely fast designing and modification of your templates.
Just change something in the Template Designer, restart the generator
and you can see how it looks now in the result output!
For more details about the Doclet GUI please see:
DocFlex/Javadoc | Doclet | Doclet GUI
3. How fast does it work?
Even though the entire JavaDoc Generator is implemented as a
set of templates, which adds an additional level
of interpretation, we have passed a very long way of optimizations.
Now, by its performance, the result doclet
(i.e. DocFlex Doclet +
templates)
may well rival with anything written directly in Java!
Here are a couple of tests that have been run on Java SE 6u2 JDK Source Code (downloaded from:
http://download.java.net/jdk6/)
using standard templates and default
generator settings.
Generation of Framed HTML Documentation
The following is the result of the generation of a framed
HTML documentation
by all Java sources of java.*, javax.*, org.* packages
(including all their subpackages), which constitute the entire
Java SE 6 API Specification
currently provided by Sun:
| Number of Java classes: |
4119 |
| Number of packages: |
210 |
| Total source code size: |
41.5 Mb (all files) |
| Generation time: |
382 sec |
| Result HTML documentation: |
106 Mb |
| Number of generated files: |
4544 |
| Computer platform: |
Intel Core 2 Duo E6600 based system / Windows XP |
| JDK version: |
1.6.0_02 |
| DocFlex/Doclet version: |
1.5.2 |
|
Generation of RTF Documentation
The following is the result of the generation of a single-file
RTF documentation
by the Java sources of
javax.swing
package and subpackages:
| Number of Java classes: |
872 |
| Total source code size: |
10.7 Mb (all files) |
| Generation time: |
102 sec |
| Result RTF document: |
24.9 Mb (with images) |
| Number of pages (A4): |
3977 |
| Computer platform: |
Intel Core 2 Duo E6600 based system / Windows XP |
| JDK version: |
1.6.0_02 |
| DocFlex/Doclet version: |
1.5.2 |
|
4. Benefits to the users
Using DocFlex/Javadoc gives the following key capabilities:
-
The ability to visually design your own documentation generated by Javadoc using only
the DocFlex Template Designer
without direct programming of any doclets in Java.
This can greatly reduce any your efforts in achieving a desirable result. At the same time,
the sophistication of informative content and formatting of such documentation will not be less
(but we believe, in most cases even greater) than that possible to achieve with the manual Java
programming.
That is because you will not be required to learn lots of complicated things and to
overcome myriads of obstacles before achieving a substantial result -- the normal way when starting anything
serious from scratch. The authors of DocFlex Technology
have already passed this way and will share that result with you.
If you, anyway, need to do some rare things that are not supported by DocFlex directly,
you will be free to do whatever you like since you can build into the DocFlex templates calls to your
own Java classes and easily exchange data between them and those templates.
-
The ability to generate your documentation in any output format supported by DocFlex.
When designing your documentation templates, you will not be needed to bother much about specifics
of any particular output format (which may be very complicated indeed). DocFlex will render your
templates in any output format it supports with the best features available in that format.
Moreover, we are constantly working on implementing new output formats as well as improving
the existing implementations. So, once you have created your templates, you could constantly improve
the quality and diversity of your documentation virtually without doing anything at all.
The only what you would need is to obtain new versions of DocFlex!
5. Future Versions
Versions 1.6
This version is the next in our pipeline.
It is going to include the following new features:
-
A new template component will be added:
Include Text Control.
This component will allow including dynamically into the generated documentation the content of any external
plain-text or pre-formatted HTML files by specified URLs or local pathnames.
-
The support in the
framed HTML documentation
such features as Navigation Menu, Class Hierarchy and Index.
Eventually, the goal is to be able to generated with only DocFlex templates the HTML JavaDoc looking
identical to the one currently generated by the
Standard Doclet.
-
The open Java API that will allow extending the DocFlex templates with custom Java classes
(more precisely, calling those classes from the templates).
This will allow you to do such things like:
-
Including dynamically generated images into the documentation
(such as class diagrams with hyperlinks and so on).
-
Analysing pieces of Java code and including into the generated documentation
the information not provided directly by the
Doclet API
(such as marked fragments of the Java code).
Next Versions
For the next major version (DocFlex/Javadoc 2.0) we plan to develop some really
serious new things:
-
First of all, we are going to support a new major output format.
Most likely, this will be the direct generation of PDF output.
We have been also considering to generate XSL-FO output instead.
This is much easier to implement and, in theory, would provide a capability to generate
PDF, PostScript, SVG, TeX and other formats automatically using freeware XSL-FO
converters. The problem is that we are not sure about the output quality possible to achieve with
those freeware converters. At the moment, it seems, there are very few of them.
Good commercial ones do exist but the prices may be prohibitive for the users...
If you have any considerations about this topic, please share
with us!
|
-
Improvements of Template Designer, such as
- drag-and-drop of template components with mouse
- "Undo" functionality
-
Self-documenting templates (i.e. a set of templates to document any other DocFlex templates).
-
Finally, we always keep in mind that there is such a thing called
Eclipse,
where the whole our technology
(in particular, the Template Designer)
eventually is going to be.
If you are interested in any other features to be supported, please do not hesitate to send us
your feature request to: support@docflex.com.
We are always happy to hear your opinion, no matter whether you are registered DocFlex/Javadoc user or not!
Moreover, depending of what feature you need, we will try to figure out how to implement this right now.
So, it's quite possible you could see your feature just in a few days within the next minor update!
|