… to avoid compile time warning about depreciated method.
…lus some minor reorganization).
…my web page.
Subclasses can decide to use different reference extensions than generated file extensions. This is useful for markdown for example where we want references point to .html while file extensions to .markdown.
…d details. The problem was that the code generated empty see also section. The reason was twofold: first the code didn't properly handle references and second, the see also list extraction code in the XMLBasedOutputGenerator(ObjectParsingAPI) category returned custom XML which could not be parsed with existing references handling extraction methods.
Instead of forcing the XMLBasedOutputGenerator subclasses dealing with the underlying XML structure (which was the main reason behind the creation of the XMLBasedOutputGenerator class), the subclasses can use extraction methods in the same way as for handling the rest of the output.
…replaced by OutputInfoProvider protocol and it's implementation, plus additional related methods, in the base OutputGenerator class.
…ed message. The users can simply add arbitrary static text to the last updated line at the bottom of generated documentation XHTML. Note that at the moment this is only supported for XHTML output. Perhaps a better approach would be to append the information to the XML itself so it would be easily accessible to any dependent output generator or even external utilities that use appledoc clean XML for their source.
…moval. The log message components were obviously generating a problem while formatting the string. By removing all information the output works. The information was not very helpful anyway. Also fixed the link in code documentation for DocSetOutputGenerator which was still pointing to the DoxygenConverter category.
…d by doxygen.
… reported by doxygen.
…utGenerator. This relieves most of the output generators from the burder of repeating creation and removal of the same sets of common output directories. Only subclasses that need to create additional subdirectories, should handle their specifics.
Some of the dependent objects still used hard coded directory and file paths from CommandLineParser. These are now properly handled through OutputInfoProvider protocol properties, similar to the was documentation set was linked with it's parent documents output generator. To even more encapsulate different output generators implementations, all paths handling is now moved from the CommandLineParser to concrete generator subclasses. This makes the code more decoupled and OOP.
…essages for DocSetOutputGenerator.
The problem was in wrong insertion of additional <base> nodes to the main <object> node. If any base node already exists, additional nodes should be inserted after it. However the test that checked for this condition was spelled incorrectly - instead of >, == was used. This is fixed now.
…or subclasses. Each concrete output generator is implemented as a subclass of OutputGenerator instead of extending DoxygenConverter by another category. This results in much cleaner class structure and responsibility division as well as much more decoupling between different output generation objects.
…utputGenerator. This way the names are more consistent with the functonality.
Instead of hard coding the extension to the clean XML, $EXTENSION placeholder string is used. This is eventually converted to proper extension by concrete GeneratorBase subclasses. Note that since documentation set generation relies on XHTMLGenerator, it needs to know how to convert the placeholders as well. This brings close coupling between the two objects, but then XHTML generator creates the foundation for the documentation set generation anyway...
Instead of "blindly" converting all detected member links to the actual references, each possible link is tested. If the given member exists, the reference is generated, otherwise an error is output so that the user can see and correct it. Note that at this moment, verbose output level would probably need to be set to make it easier to pinpoint the error, although project find would also do it anyway.
This is more or less cosmetic, but it fits nicer to the class reference index descriptions and avoids repetition with the main title.
This allows output to show all known base classes including references to the actual base descriptions.
…he Xcode documentation window.
…based error message and only then throwing the error. In most cases the error is not directly related to the context, so it's message is confusing as to where the error happened and what the utility was doing. The new messages should handle this better.