-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0_01
-
tiger
-
generic
-
generic
This is a request for refactoring of the standard doclet
implementation to pull out its algorithms and utilites to make them
available to other doclets that emulate the standard doclet.
This would be of interest to the MIF doclet, LaTex doclet, and others.
This refactoring would cover the generation of content and functionality
independent of its formatting markup:
Shared content -- such things as:
- summary tables
- details of packages, classes and members
- inheritance trees (overview tree, package tree, class tree)
- how names are qualified in links (@see, {@link}, argument types, return
types, etc)
- constant values page, serialized form page
Shared functionality and utilities -- such things as:
- how command line options are handled
- custom tags and taglets
- extending taglets to use standard inline tags
- computing relative paths to the docroot
NOTE: We are careful not to call this an API or SPI, as it will
remain an implementation, providing the flexibility for future
extension and improvement. Others may use the interfaces
and utilities at their own risk, knowing full well in advance
that they may change at any time without notice.
implementation to pull out its algorithms and utilites to make them
available to other doclets that emulate the standard doclet.
This would be of interest to the MIF doclet, LaTex doclet, and others.
This refactoring would cover the generation of content and functionality
independent of its formatting markup:
Shared content -- such things as:
- summary tables
- details of packages, classes and members
- inheritance trees (overview tree, package tree, class tree)
- how names are qualified in links (@see, {@link}, argument types, return
types, etc)
- constant values page, serialized form page
Shared functionality and utilities -- such things as:
- how command line options are handled
- custom tags and taglets
- extending taglets to use standard inline tags
- computing relative paths to the docroot
NOTE: We are careful not to call this an API or SPI, as it will
remain an implementation, providing the flexibility for future
extension and improvement. Others may use the interfaces
and utilities at their own risk, knowing full well in advance
that they may change at any time without notice.