Discussion

If YES, HTML files from html subdirectory in outputPath are moved to proper subdirectory within docset output files, then helper files are generated from parsed data. Documentation set files are also indexed. If NO, HTML files are left in the output path.

Discussion

If YES, any undocumented overriden method or property is searched for in known super classes and adopted protocols and if documentation is found there, it is copied over. This works great for objects which would otherwise only show class documentation and no member. It's also how Apple documentation uses. Defaults to YES.

Note: This property works together with keepUndocumentedObjects and keepUndocumentedMembers. To understand how they are used, read documentation for keepUndocumentedObjects.

Discussion

It's recommended to check if a path string ends with any of the given paths before processing it. This should catch directory and file names properly as directories are processed first.

Discussion

If YES, temporary files used for indexing and removed, then documentation set bundle is created from the files from docset output path and is moved to docsetInstallPath. If NO, all documentation set files are left in output path.

Discussion

If YES, all intermediate files (i.e. HTML files and documentation set files) are kept in output path. If NO, only final results are kept. This setting not only affects how the files are being handled, it also affects performance. If intermediate files are not kept, appledoc moves files between various generation phases, otherwise it copies them. So it's prefferable to leave this option to NO. This option only affects output files, input source files are always left intact!

Discussion

If YES, all the sections from category or extension documentation are preserved. In such case, prefixMergedCategoriesSectionsWithCategoryName may optionally be used to prefix section name with category name or not. If NO, category or extension sections are ignored and a single section with category name is created in the class.

Default value is NO. If you use many sections within the categories, you should probably leave this option unchanged as preserving all category sections might yield fragmented class documentation. Experiment a bit to see what works best for you.

Note: This option is ignored unless mergeCategoriesToClasses is used.

Discussion

If YES, all methods from categories and extensions are merged to their classes. If NO, categories are left as independent objects in generated output. This is the main categories merging on/off switch, it merely enables or disables merging, other category merging settings define how exactly the methods from categories and extensions are merged into their classes.

Default value is YES and should be left so as this seems to be the way Apple has it's documentation generated.

Important: Only categories for known project classes are merged. Categories to other framework classes, such as Foundation, AppKit or UIKit are not merged. In other words: only if the class source code is available on any of the given input paths, and is properly documented, it gets it's categories and extension methods merged! Also note that this option affects your documentation links - if any link is pointing to category that's going to be merged, it will be considered invalid link, so it's best to decide whther to merge categories of nor in advance and then consistently use properly formatted links.

Discussion

If YES, all merged section names from categories are prefixed with category name to make them more easily identifiable. If NO, section names are not changed. The first option is useful in case end users of your code are aware of different categories (if you're writting a framework for example). On the other hand, if you're using categories mostly as a way to split class definition to multiple files, you might want to keep this option off.

Note: This option is ignored unless mergeCategoriesToClasses and keepMergedCategoriesSections is used. The option is also ignored for extensions; only section names are used for extensions!

Discussion

If YES, installed documentation set is packaged for publishing - an atom feed is created and documentation set is archived. If the atom feed file is alreay found, it is updated with new information. Both, the feed and archived docset files are located within outputPath. If NO, documentation set is not prepared for publishing.

Discussion

If YES, first paragraph is repeated in members description, otherwise not.

Discussion

Although appledoc deducts this information from other values, it's better to warn the user as deducted information doesn't necessarily produce correct results.

Note that the warning is only issued if documentation set creation is requested.

Discussion

Although appledoc still generates output in current directory, it's better to warn the user as in most cases this is not what she wants (for example if appledoc is invoked from Xcode build script, current working directory might point to some unpredicted location). appledoc also writes the exact path that will be used for generating output.

Note that in case documentation set is installed to Xcode, setting output path is irrelevant as all files from output are moved to locations Xcode uses for finding documentation sets.

Discussion

This is useful for generating hrefs from one object HTML file to another. This is the swiss army knife king of a method for all hrefs generation. It works for any kind of links:

• Index to top-level object (if source is nil).
• Index to a member of a top-level object (if source is nil).
• Top-level object to same top-level object.
• Top-level object to a different top-level object.
• Top-level object to one of it's members.
• Member object to it's top-level object.
• Member object to another top-level object.
• Member object to another member of the same top-level object.
• Member object to a member of another top-level object.

Discussion

This is simply a helper method for htmlReferenceForObject:fromSource:, passing the given object as object parameter and nil as source.

Discussion

This should only be used for creating anchors that need to be referenced from other parts of the same HTML file. The method works for top-level objects as well as their members.

Discussion

This message should be sent once all the values have been set. It is a convenience method that prepares all values that can use placeholder strings. From this point on, the rest of the application can simply use properties to get final values instead of sending stringByReplacingOccurencesOfPlaceholdersInString: all the time.

Note that stringByReplacingOccurencesOfPlaceholdersInString: is still available for cases where placeholder strings may be used elsewhere (template files for example).

Discussion

This method provides application-wide string placeholders replacement functionality. It replaces all known placeholders with actual values from the receiver. Placeholders are identified by a dollar mark, followed by placeholder name. The following placeholders are supported (note that case is important!):

• %PROJECT: Replaced by projectName value.
• %PROJECTID: Replaced by projectIdentifier value.
• %COMPANY: Replaced by projectCompany value.
• %COMPANYID: Replaced by companyIdentifier value.
• %VERSION: Replaced by projectVersion value.
• %VERSIONID: Replaced by versionIdentifier value.
• %DOCSETBUNDLEFILENAME: Replaced by docsetBundleFilename value.
• %DOCSETATOMFILENAME: Replaced by docsetAtomFilename value.
• %DOCSETPACKAGEFILENAME: Replaced by docsetPackageFilename value.
• %YEAR: Replaced by current year as four digit string.
• %UPDATEDATE: Replaced by current date in the form of year, month and day with format YYYY-MM-DD. For example 2010-11-30.