consoleDoc.h

Engine/source/console/consoleDoc.h

More...

Detailed Description

  1
  2//-----------------------------------------------------------------------------
  3// Copyright (c) 2012 GarageGames, LLC
  4//
  5// Permission is hereby granted, free of charge, to any person obtaining a copy
  6// of this software and associated documentation files (the "Software"), to
  7// deal in the Software without restriction, including without limitation the
  8// rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
  9// sell copies of the Software, and to permit persons to whom the Software is
 10// furnished to do so, subject to the following conditions:
 11//
 12// The above copyright notice and this permission notice shall be included in
 13// all copies or substantial portions of the Software.
 14//
 15// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 16// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 17// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 18// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 19// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 20// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 21// IN THE SOFTWARE.
 22//-----------------------------------------------------------------------------
 23
 24// This file exists solely to document consoleDoc.cpp
 25
 26/// @defgroup  script_autodoc Script Auto-Documentation
 27/// @ingroup   console_system Console System
 28///
 29/// @section script_autodoc_using        Using Script Auto-Documentation
 30///
 31/// There are on the order of three hundred functions exposed to the script language
 32/// through the console. It is therefore extremely important that they be documented,
 33/// but due to their number, it is difficult to maintain a seperate reference document.
 34/// 
 35/// Therefore, a simple documentation system has been built into the scripting engine. It
 36/// was initially added by Mark Frohnmayer, and later enhanced by Ben Garney. The
 37/// scripting engine supports grouping functions and methods, to help organize the 
 38/// several hundred functions, as well as associating a "usage string" with functions and
 39/// groups.
 40///
 41/// @note The results of a console doc dump will vary depending on when you run it. If
 42///       you run it, for example, while in the game menu, it won't output any data for
 43///       the script-defined classes which are defined for gameplay. To get comprehensive
 44///       documentation, you may need to write a special script that will get all your
 45///       classes loaded into the scripting engine.
 46///
 47/// The script documentation system is designed to output a dump of the current state
 48/// of the scripting engine in a format understandable by Doxygen. It does this by 
 49/// traversing the namespace/class hierarchy in memory at the time of the dump, and
 50/// outputting psuedo-C++ code equivalent to this class hierarchy.
 51/// 
 52/// @subsection script_autodoc_using_script For the Scripter...
 53///
 54/// Currently, there is no way to associate usage strings or other documentation with script code
 55/// like you can with C++ code.
 56///
 57/// You can get a list of all the methods and fields of an object from any object which inherits
 58/// from SimObject (ie, every object), as well as the documentation on those objects by using the
 59/// dump() method from the console:
 60///
 61/// @code
 62/// ==>$foo = new SimObject();
 63/// ==>$foo.dump();
 64/// Member Fields:
 65/// Tagged Fields:
 66/// Methods:
 67///   delete() - obj.delete()
 68///   dump() - obj.dump()
 69///   getClassName() - obj.getClassName()
 70///   getGroup() - obj.getGroup()
 71///   getId() - obj.getId()
 72///   getName() - obj.getName()
 73///   getType() - obj.getType()
 74///   save() - obj.save(fileName, <selectedOnly>)
 75///   schedule() - object.schedule(time, command, <arg1...argN>);
 76///   setName() - obj.setName(newName)
 77/// @endcode
 78///
 79/// In the Torque example app, there are two functions defined in common\\client\\scriptDoc.tscript
 80/// which automate the process of dumping the documentation. They make use of the ConsoleLogger
 81/// object to output the documentation to a file, and look like this:
 82///
 83/// @note You may want to add this code, or code like it, to your project if you have
 84///       rewritten the script code in common. 
 85///
 86/// @code
 87/// // Writes out all script functions to a file
 88/// function writeOutFunctions() {
 89///    new ConsoleLogger( logger, "ConsoleFunctions.txt", false );
 90///    dumpConsoleFunctions();
 91///    logger.delete();
 92/// }
 93/// 
 94/// // Writes out all script classes to a file
 95/// function writeOutClasses() {
 96///    new ConsoleLogger( logger, "scriptClasses.txt", false );
 97///    dumpConsoleClasses();
 98///    logger.delete();
 99/// }
100/// @endcode
101///
102/// @subsection script_autodoc_using_coder  For the C++ Coder...
103///
104/// @note <b>It is of the utmost important that you keep your usage strings up to date!</b>
105///       Usage strings are the only way that a scripter has to know how to use the methods,
106///       functions, and variables you expose. Misleading, missing, or out of date documentation
107///       will make their lives much harder - and yours, too, because you'll have to keep
108///       explaining things to them! So make everyone's lives easier - keep your usage strings
109///       clear, concise, and up to date.
110///
111/// There are four types of items which can be documented using the autodocumentation system: 
112///   - <b>Fields</b>, which are defined using the addField() calls. They are documented
113///     by passing a string to the usage parameter.
114///   - <b>Field groups</b>, which are defined using the beginGroup() and endGroup() calls.
115///     They are documented by passing a descriptive string to the usage parameter.
116///   - <b>Method groups</b>, which are defined using beginCommandGroup(), endCommandGroup(),
117///     ConsoleMethodGroupEnd(), ConsoleMethodGroupBegin(), ConsoleFunctionGroupEnd(), and
118///     ConsoleFunctionGroupBegin().
119///   - <b>Methods and functions</b>, which are defined using either SimObject::addCommand(),
120///     the ConsoleMethod() macro, or the ConsoleFunction() macro. Methods and functions are
121///     special in that the usage strings should be in a specific format, so
122///     that parameter information can be extracted from them and placed into the Doxygen
123///     output. 
124///
125/// You can use standard Doxygen commands in your comments, to make the documentation clearer.
126/// Of particular use are \@returns, \@param, \@note, and \@deprecated.
127///
128/// <b>Examples using global definitions.</b>
129///
130/// @code
131///    // Example of using Doxygen commands.
132///    ConsoleFunction(alxGetWaveLen, S32, 2, 2, "(string filename)"
133///                    "Get length of a wave file\n\n"
134///                    "@param filename File to determine length of.\n"
135///                    "@returns Length in milliseconds.")
136///
137///    // A function group...
138///    ConsoleFunctionGroupBegin(Example, "This is an example group! Notice that the name for the group"
139///                                       "must be a valid identifier, due to limitations in the C preprocessor.");
140///
141///    // ConsoleFunction definitions go here.
142///
143///    ConsoleFunctionGroupEnd(Example);
144///
145///    // You can do similar things with methods...
146///    ConsoleMethodGroupBegin(SimSet, UsefulFuncs, "Here are some useful functions involving a SimSet.");
147///    ConsoleMethod(SimSet, listObjects, void, 2, 2, "set.listObjects();")
148///    ConsoleMethodGroupEnd(SimSet, UsefulFuncs, "Here are some more useful functions involving a SimSet.");
149/// @endcode
150///
151/// <b>Examples using addField</b>
152///
153/// @note Using addCommand is strongly deprecated.
154///
155/// @code
156///   // Example of a field group.
157///   addGroup( "Logging", "Things relating to logging." );
158///   addField( "level",   TYPEID< ConsoleLogLevel >(),     Offset( mLevel,    ConsoleLogger ) );
159///   endGroup( "Logging" );
160/// @endcode
161///
162/// @section script_autodoc_makingdocs   How to Generate Script Docs
163///
164/// Script docs can be generated by running the dumpConsoleFunctions() and
165/// dumpConsoleClasses(), then running the output through Doxygen. There is an
166/// example Doxygen configuration file to do this at
167/// doc\\doxygen\\html\\script_doxygen.html.cfg. Doxygen will parse the psuedo-C++
168/// generated by the console doc code and produce a class hierarchy and documentation
169/// of the global namespace. You may need to tweak the paths in the configuration file
170/// slightly to reflect your individual setup.
171///
172/// @section script_autodoc_internals Script Auto-Documentation Internals
173/// 
174/// The consoleDoc system works by inserting "hidden" entries in Namespace and
175/// AbstractClassRep; these hidden entries are assigned special type IDs so that
176/// they aren't touched by the standard name resolution code. At documentation
177/// creation time, the dumpConsole functions iterate through the Namespace hierarchy
178/// and the AbstractClassRep data and extract this "hidden" information, outputting
179/// it in a Doxygen-compatible format.
180///
181/// @note You can customize the output of the console documentation system by modifying
182///       these functions:
183///            - printClassHeader()
184///            - printClassMethod()
185///            - printGroupStart()
186///            - printClassMember()
187///            - printGroupEnd()
188///            - printClassFooter()
189///
190/// @note There was once support for 'overloaded' script functions; ie, script functions
191///       with multiple usage strings. Certain functions in the audio library used this.
192///       However, it was deemed too complex, and removed from the scripting engine. There
193///       are still some latent traces of it, however.
194