I'm trying to setup jsdoc in my codeing. The files are like the image bellow. The module is actaually the folder skeleton. What do I need to add to the two class.js files to get them included in my module generated with jsdoc?
Right now it is generated like this. It doesn't contain the information of the classes.
If I move my comment block from to my class files I get the image bellow, and if I place it in both files all info is duplicated.
The comment block I have is this
/**
* Module defining the database structure. This module contains all table models as well as any validations or functions related to those models.
* #module Skeleton
* #author E. Koster
* #version 1.0.0
* #since 2.0.0
*/
I found it, it's #memberOf module:MODULE_NAME what I was looking for.
Related
There are 2 functions in TYPO3 which seem to more or less do the same:
ExtensionManagementUtility::addModule
/**
* Adds a module (main or sub) to the backend interface
* FOR USE IN ext_tables.php FILES
ExtensionUtility::registerModule
/**
* Registers an Extbase module (main or sub) to the backend interface.
* FOR USE IN ext_tables.php FILES
So, according to the comments, they basically do the same, but one registers and one adds and for one it's an Extbase module. I have seen examples for both online and seen TYPO3 extensions use one or the other methods.
Which of these methods should be use to create a TYPO3 backend-module and what is the difference?
I can just use one or the other methods, but I would like to get some more guidance on these general things and what is the best practice for the future.
The obvious answer is probably, if you use Extbase, you use registerModule, if not, you use addModule. Ok, but then, why does the core do it this way in some cases and that way in the other?
Another obvious answer is that registerModule calls addModule.
See also this comment.
With addModule you just add a new Module into the left navigation bar.
With registerModule you do some pre-configuration for extbase. Have a look into the code, all controller->action combinations will be registered globally. A vender will be set and please have a look at the very last line: It calls addModule from above.
Additionally, it looks like ExtensionUtility::registerModule() is used for modules based on Extbase, and ExtensionManagementUtility::addModule() otherwise (see BackendModuleApi)
I'm working with legacy PHP code that has a lot of functions with one-line comments (// ...).
But for documentation generators like doxygen and phpDocumentor to document those functions to the fullest extent, the functions need to be in DocBlock format:
/**
* Summary
*
* Description
*
* #param etc
*/
Does NetBeans provide a way to automatically generate a DocBlock comment given a method signature and / or a one-line comment preceding a function?
Use /** to generate the DocBlock.
I would be looking to customize this "/**" macro shortcut. It would be awesome if I could also find it in the tools.
I would like to change the page layout for a single source file. The other pages should be generated as before.
Other option would be to generate a seperate page referencing the relevant content from that source file.
To make it a little more concrete, I have the following file and would like to generate a documentation file only including these comments without the printing of includes, etc.
And as said this behavior is only intended for this single source file.
/**
* TreeNode
*xxx
*/
class TreeNode
/**
* TreeNode2
*xxx
*/
class TreeNode2
Thanks a lot!
I think your best approach is to exclude the bits you don't want by surrounding those parts in the file with #cond and #endcond markers. (The #if 0 of doxygen.)
In that way your file processing won't be complicated with file-specific layouts (which I'm not sure is possible anyway) and the 'special' handling of that file is visible within that file's content.
I am trying to use Doxygen Automatic link generation to document some enum types. However, it is not generating links for the global enum types. It does generates links for the global struct types. Is there something I am missing? I am using the example provided on the link above. As required, I have documented the file in which the types are defined.
update1: I am using Doxygen version 1.6.3
update2: global structs are ok
Yeah, I had that same issue; i think doxygen thinks they are private or something stupid like that. Try using the \public. Don't forget to do the /*! on the first line
/*! \public
* Enum description goes here
*/
typedef enum {
/**
* Printer control language ZPL
*/
PRINTER_LANGUAGE_ZPL,
/**
* Printer control language CPCL
*/
PRINTER_LANGUAGE_CPCL
} PrinterLanguage;
I was having the same issue. Some header files generated a link for enums and other header files did not. You must explicitly document the file.
Here is a excerpt from this page int the documentation.
http://www.doxygen.nl/manual/docblocks.html#memberdoc
To document a global C function, typedef, enum or preprocessor
definition you must first document the file that contains it (usually
this will be a header file, because that file contains the information
that is exported to other source files).
Attention
Let's repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum, macros, etc), you must
document the file in which they are defined. In other words, there
must at least be a
/*! \file */
or a
/** #file */
line in this file.
I am building a Qt based project, and many Qt classes are found in the target documentation.
How can I tell Doxygen to disable documentation generation for some classes? For Q.*?
Working under the assumption that what you have is something like this: (The question is a little unclear in this regard)
/**
* Some documentation for class X
*/
class X: public osg::Drawable {
...
}
And your problem is that you want to include documentation for class X, but not for class osg::Drawable, the proper technique is to use EXCLUDE_SYMBOLS. For example, in the case above use
EXCLUDE_SYMBOLS = osg::Drawable
If you want to be slightly more rigorous, you can use
EXCLUDE_SYMBOLS = osg::Drawable \
Drawable
Wild-cards are also allowed, so this will also work
EXCLUDE_SYMBOLS = osg::*
If \internal tag does not work, you can try \cond ... \endcond tags for marking a portion of code to be hidden from Doxygen.
EDIT
If you want to exclude specific files, you can use EXCLUDE_PATTERNS variable in Doxyfile configuration file.
Its not the best way but one can mark some portion of the documentation (class, members, ...) with the private. This prevents the piece of code from being included in the output documentation. (I use this to hide copy/move constructors/operators from appearing in the API documentation.)
/*!
* \brief This is included.
*/
class API
{
public:
/*!
* \brief So is this.
*/
API() noexcept;
/// \private
~API() noexcept; /* But this not, though technically public. */
private:
int m_version; /* This is not either. */
}
One should note though that this is a Doxygen extension for PHP, which according to the documentation they should not be used.
For PHP files there are a number of additional commands, that can be used inside classes to make members public, private, or protected even though the language itself doesn't support this notion.
The other option is to use the solution mouviciel provided, but it requires at least two lines.
Though not the correct answer for the detailed question it might be helpful for readers of the question title (like me). It works for classe too!