GBApplicationSettingsProvider Class Reference

Discussion

Returns relative HTML reference to the given object from the context of the given source object.

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

Returns relative HTML reference to the given object from the context of index file.

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

@pram object The object for which to generate the reference to. @return Returns the reference string. @exception NSException Thrown if object is nil . @see htmlReferenceForObject:fromSource: @see htmlReferenceNameForObject:

Discussion

Returns HTML reference name for the given object.

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

Replaces all occurences of placeholder strings in all related values of the receiver.

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

Replaces all placeholders occurences in the given string.

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.
• $COMPANY : Replaced by projectCompany value.
• $VERSION : Replaced by projectVersion 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 .

Discussion

Specifies whether documentation set should be created from the HTML files.

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

Specifies whether undocumented inherited methods or properties should be searched for in known places.

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

The list of all full or partial paths to be ignored.

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

Specifies whether the documentation set should be installed or not.

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

Indicates whether category or extension sections should be preserved when merging into extended class.

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

Indicates whether categories should be merges to classes they extend or not.

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

Indicates whether merged section names from categories should be prefixed with category name.

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

Indicates whether appledoc will warn if --company-id argument is not given.

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

Indicates whether appledoc will warn if --output argument is not given.

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.