Last 7 days

• Dec 23, 2009

  issue 174 (Allow user to specify link text) commented on by ryan.gustafson   -   Add in the following to support the JavaDoc inline {@code code} tag: str = str.replace(/\{@code ([^}]+)\}/gi, function(match, code) { return '<code>' + code + '</code>'; } );

  Add in the following to support the JavaDoc inline {@code code} tag: str = str.replace(/\{@code ([^}]+)\}/gi, function(match, code) { return '<code>' + code + '</code>'; } );

Last 30 days

• Dec 18, 2009

  issue 174 (Allow user to specify link text) commented on by ryan.gustafson   -   I hacked the following up for use at work today: /** Find symbol {@link ...} strings in text and turn into html links */ function resolveLinks(str, from) { str = str.replace(/\{@link ([^}]+)\}/gi, function(match, symbolName) { symbolName = symbolName.trim(); var index = symbolName.indexOf(' '); if (index > 0) { var label = symbolName.substring(index + 1); symbolName = symbolName.substring(0, index); return new Link().toSymbol(symbolName).withText(label); } else { return new Link().toSymbol(symbolName); } } ); return str; }

  I hacked the following up for use at work today: /** Find symbol {@link ...} strings in text and turn into html links */ function resolveLinks(str, from) { str = str.replace(/\{@link ([^}]+)\}/gi, function(match, symbolName) { symbolName = symbolName.trim(); var index = symbolName.indexOf(' '); if (index > 0) { var label = symbolName.substring(index + 1); symbolName = symbolName.substring(0, index); return new Link().toSymbol(symbolName).withText(label); } else { return new Link().toSymbol(symbolName); } } ); return str; }
• Dec 05, 2009

  issue 271 (Cannot find function charAt in object true) changed by micmath   -  

  Status: Accepted

  Labels: Type-Defect Priority-Low

  Status: Accepted

  Labels: Type-Defect Priority-Low
• Dec 05, 2009

  issue 273 (Provide small example JS files in the jsdoc distribution) Status changed by micmath   -   I'm sorry you are having trouble getting started. I'm writing a fairly complete "Getting Started" tutorial right now actually, but if you take a look at the output from running your example code above you should see that JsDoc Toolkit is trying to tell you what the problem is: >> WARNING: Trying to document convert as a member of undocumented symbol foo. This means you are adding documentation for the method named 'convert' before you've documented it's parent 'foo'. It's easy to fix, just document 'foo'. The following should produce no warnings: /** @namespace */ var foo = { }; /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */ foo.convert = function(s) { return "jjj"; };

  Status: WontFix

  I'm sorry you are having trouble getting started. I'm writing a fairly complete "Getting Started" tutorial right now actually, but if you take a look at the output from running your example code above you should see that JsDoc Toolkit is trying to tell you what the problem is: >> WARNING: Trying to document convert as a member of undocumented symbol foo. This means you are adding documentation for the method named 'convert' before you've documented it's parent 'foo'. It's easy to fix, just document 'foo'. The following should produce no warnings: /** @namespace */ var foo = { }; /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */ foo.convert = function(s) { return "jjj"; };

  Status: WontFix
• Dec 04, 2009

  issue 273 (Provide small example JS files in the jsdoc distribution) commented on by ithinkihaveacat   -   When I say generating documentation for test.js doesn't work, I mean that files are generated in the "out" directory, and the "File Index" lists test.js, but I can't find any documentation for foo.convert on the "Built-In Namespace _global_" page or anywhere else. (I suppose I would have expected a "foo" namespace page to be generated.)

  When I say generating documentation for test.js doesn't work, I mean that files are generated in the "out" directory, and the "File Index" lists test.js, but I can't find any documentation for foo.convert on the "Built-In Namespace _global_" page or anywhere else. (I suppose I would have expected a "foo" namespace page to be generated.)
• Dec 04, 2009

  issue 272 (@example documentation does not explain how to end the examp...) commented on by ithinkihaveacat   -   Sorry, I'm having trouble getting jsdoc-toolkit to work at all. I was originally interested in @example simply because I was wondering about the syntax (I'm not actually generating documentation at this time), and from the URL above I couldn't figure out how to "close" an @example. When I get jsdoc working (see issue 273 ) I'll get back to you--maybe it does "just work" but I think it would be useful if the documentation either explicitly said, or implied via the example, that closing @example tags is not necessary.

  Sorry, I'm having trouble getting jsdoc-toolkit to work at all. I was originally interested in @example simply because I was wondering about the syntax (I'm not actually generating documentation at this time), and from the URL above I couldn't figure out how to "close" an @example. When I get jsdoc working (see issue 273 ) I'll get back to you--maybe it does "just work" but I think it would be useful if the documentation either explicitly said, or implied via the example, that closing @example tags is not necessary.
• Dec 04, 2009

  issue 273 (Provide small example JS files in the jsdoc distribution) reported by ithinkihaveacat   -   Perhaps this is just me, but I'm finding it very difficult to get started with jsdoc. I'd like to suggest that you include a sample JS file in the jsdoc-toolkit distribution (that could be referenced from README.txt), and maybe create a simple "Getting Started" page on Google Code. As an example of the trouble I'm having, I'm trying to generate documentation for the file test.js: var foo = { }; /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */ foo.convert = function(s) { return "jjj"; }; However, if I run jsdoc-toolkit with the command line java -jar jsrun.jar app/run.js -a -t=templates/jsdoc test.js I get some generated files in the "out" directory, but there's no actual generated documentation. It's quite likely that there's some sort of syntax error in my file, but it would be useful if there were a guaranteed- to-work sample.js in the distribution that I can expect to work. I tried adding @name and @function tags as mentioned in the FAQ, but this didn't make any difference. Replacing the body with function helloWorld() { alert('Hello, World'); } did produce documentation, but I'm unsure why my test file produces nothing. Would it be possible to include a sample.js that incorporates a few examples of different tags, and incorporate this into the "USAGE" section of README.txt?

  Perhaps this is just me, but I'm finding it very difficult to get started with jsdoc. I'd like to suggest that you include a sample JS file in the jsdoc-toolkit distribution (that could be referenced from README.txt), and maybe create a simple "Getting Started" page on Google Code. As an example of the trouble I'm having, I'm trying to generate documentation for the file test.js: var foo = { }; /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */ foo.convert = function(s) { return "jjj"; }; However, if I run jsdoc-toolkit with the command line java -jar jsrun.jar app/run.js -a -t=templates/jsdoc test.js I get some generated files in the "out" directory, but there's no actual generated documentation. It's quite likely that there's some sort of syntax error in my file, but it would be useful if there were a guaranteed- to-work sample.js in the distribution that I can expect to work. I tried adding @name and @function tags as mentioned in the FAQ, but this didn't make any difference. Replacing the body with function helloWorld() { alert('Hello, World'); } did produce documentation, but I'm unsure why my test file produces nothing. Would it be possible to include a sample.js that incorporates a few examples of different tags, and incorporate this into the "USAGE" section of README.txt?
• Dec 03, 2009

  issue 272 (@example documentation does not explain how to end the examp...) Status changed by micmath   -   All tags (@example is no exception) end when either: a new tag starts, or the doc comment itself ends. There are no "ending tags" for any tag. Are you saying the example you cited doesn't work?

  Status: MoreInfoRequired

  All tags (@example is no exception) end when either: a new tag starts, or the doc comment itself ends. There are no "ending tags" for any tag. Are you saying the example you cited doesn't work?

  Status: MoreInfoRequired
• Dec 03, 2009

  issue 272 (@example documentation does not explain how to end the examp...) reported by ithinkihaveacat   -   The documentation for the @example tag at http://code.google.com/p/jsdoc-toolkit/wiki/TagExample doesn't indicate how to indicate that a code example has ended. This is necessary if the @example is embedded in a larger docblock. For example: /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */

  The documentation for the @example tag at http://code.google.com/p/jsdoc-toolkit/wiki/TagExample doesn't indicate how to indicate that a code example has ended. This is necessary if the @example is embedded in a larger docblock. For example: /** * Converts a wizzle to a wozzle. * * @example * foo.convert("ffff"); * * NOTE: Only works if the wizzle is less than 100 characters long. * * @param {String} s string to convert * @return {String} */
• Nov 30, 2009

  issue 218 (Still getting WARNING: Trying to document ...) commented on by georgios...@hotmail.com   -   PS: Note that the error is thrown at the this.name = ""; line of the original demo code and not on a method/prop.

  PS: Note that the error is thrown at the this.name = ""; line of the original demo code and not on a method/prop.
• Nov 30, 2009

  issue 218 (Still getting WARNING: Trying to document ...) commented on by georgios...@hotmail.com   -   I think the 1st point here is the message itself and how misleading it is and the 2nd point is the jsdtk inability to identify that 'this' has the @ignore tag. The sample code is a demo only and a larger scale project is behind it. To be more specific we have classes named with underscore (_) to flag for obfuscation and code compacting some of which we would like to attach to a namespace. Hence, what we have is: class _a { } and var company.com.className = _a; In the above example we wish to document _a's methods and properties and assign the docs to the derived company.com.className link which has a different, more complete, name. Possibly an bad architectural decision but I just wanted to help give the bigger picture.

  I think the 1st point here is the message itself and how misleading it is and the 2nd point is the jsdtk inability to identify that 'this' has the @ignore tag. The sample code is a demo only and a larger scale project is behind it. To be more specific we have classes named with underscore (_) to flag for obfuscation and code compacting some of which we would like to attach to a namespace. Hence, what we have is: class _a { } and var company.com.className = _a; In the above example we wish to document _a's methods and properties and assign the docs to the derived company.com.className link which has a different, more complete, name. Possibly an bad architectural decision but I just wanted to help give the bigger picture.

Earlier this year

• Nov 28, 2009

  issue 271 (Cannot find function charAt in object true) commented on by frans.lundberg   -   Thank you! The error message is still a bug though. Always difficult to get those right - I know.

  Thank you! The error message is still a bug though. Always difficult to get those right - I know.
• Nov 27, 2009

  issue 271 (Cannot find function charAt in object true) commented on by frodenius   -   it should be -t=templates\jsdoc

  it should be -t=templates\jsdoc
• Nov 27, 2009

  issue 271 (Cannot find function charAt in object true) reported by frans.lundberg   -   What steps will reproduce the problem? C:\frans\pr\jsdoc_toolkit-2.3.2>java -jar jsrun.jar app/run.js -t templates\jsdoc I:\Inetpub\fap_se\distributor\member\memberOffers.asp Gives following output: js: uncaught JavaScript runtime exception: TypeError: Cannot find function charAt in object true. version: sdoc_toolkit-2.3.2 OS: Windows XP java VM: java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

  What steps will reproduce the problem? C:\frans\pr\jsdoc_toolkit-2.3.2>java -jar jsrun.jar app/run.js -t templates\jsdoc I:\Inetpub\fap_se\distributor\member\memberOffers.asp Gives following output: js: uncaught JavaScript runtime exception: TypeError: Cannot find function charAt in object true. version: sdoc_toolkit-2.3.2 OS: Windows XP java VM: java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
• Nov 24, 2009

  issue 268 (Need a way to define external plugins) commented on by j...@metrocat.org   -   I've updated the patch to include the command line options. I only ever run the tool using the -c option, so I didn't notice this issue. I also fixed the code that loads the plugins. It only worked when the plugin folder was relative to SYS.pwd (whatever that is).

  I've updated the patch to include the command line options. I only ever run the tool using the -c option, so I didn't notice this issue. I also fixed the code that loads the plugins. It only worked when the plugin folder was relative to SYS.pwd (whatever that is).
• Nov 24, 2009

  issue 269 (The source generation/highlighting isn't very flexible.) commented on by j...@metrocat.org   -   Ah, if this functionality is considered to be a part of the template, then I could just fold it into my template (which is located outside the standard jsdoc-toolkit distribution). It might be worth considering moving some of the plugins into a samples folder, since I'm certain executing even empty plugins adds up to significant CPU cycles when documenting a large project. Maybe the right answer here is to make a source.tmpl file and pour the formatted code into that...

  Ah, if this functionality is considered to be a part of the template, then I could just fold it into my template (which is located outside the standard jsdoc-toolkit distribution). It might be worth considering moving some of the plugins into a samples folder, since I'm certain executing even empty plugins adds up to significant CPU cycles when documenting a large project. Maybe the right answer here is to make a source.tmpl file and pour the formatted code into that...
• Nov 24, 2009

  issue 269 (The source generation/highlighting isn't very flexible.) Status changed by micmath   -   The publishWrcHilite plugin is only ever called from the jsdoc template, so I consider it to be part of the template, which admittedly is in the "default installation". I very strongly encourage people to make their own templates, so I don't really mind that the standard one is inflexible. That said, I see your point about the header, footer. I may implement it slightly differently though. Thinks...

  Status: Accepted

  The publishWrcHilite plugin is only ever called from the jsdoc template, so I consider it to be part of the template, which admittedly is in the "default installation". I very strongly encourage people to make their own templates, so I don't really mind that the standard one is inflexible. That said, I see your point about the header, footer. I may implement it slightly differently though. Thinks...

  Status: Accepted
• Nov 23, 2009

  issue 269 (The source generation/highlighting isn't very flexible.) commented on by j...@metrocat.org   -   Well, I don't want to modify the default jsdoc-toolkit installation. So I was trying to enhance the existing plugin, which I think will execute regardless of whether I create an additional plugin. I also suspect that many folks are more likely to update some HTML & CSS rather than write a plugin.

  Well, I don't want to modify the default jsdoc-toolkit installation. So I was trying to enhance the existing plugin, which I think will execute regardless of whether I create an additional plugin. I also suspect that many folks are more likely to update some HTML & CSS rather than write a plugin.
• Nov 23, 2009

  issue 268 (Need a way to define external plugins) Status changed by micmath   -   This patch is incomplete, adding a new commandline option requires a short and long name and this must listed in the help message. -p is already taken for "private". -t is for templates, maybe -g for plugins?

  Status: Accepted

  This patch is incomplete, adding a new commandline option requires a short and long name and this must listed in the help message. -p is already taken for "private". -t is for templates, maybe -g for plugins?

  Status: Accepted
• Nov 23, 2009

  issue 269 (The source generation/highlighting isn't very flexible.) Status changed by micmath   -   Not sure what I think about this one. Isn't creating your own plugin as easy as creating a new template? Why can't you just create your own source code generation plugin based on the existing one?

  Status: MoreInfoRequired

  Not sure what I think about this one. Isn't creating your own plugin as easy as creating a new template? Why can't you just create your own source code generation plugin based on the existing one?

  Status: MoreInfoRequired
• Nov 23, 2009

  issue 270 (Patch: Allow dash after name) Status changed by micmath   -  

  Status: Accepted

  Status: Accepted
• Nov 23, 2009

  issue 270 (Patch: Allow dash after name) reported by j...@metrocat.org   -   The doc comments can get a bit complex when you start adding types and names and descriptions. Consider the following: @param {Object} parameters A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding. Once the documentation is generated, this looks nice. But when reading the code, this can be a bit difficult to read. Attached find a patch that enables a dash between the name and the description. Like the following: @param {Object} [parameters] - A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding. The dash is only removed when it appears on the same line as the name. For example, this tag would not have the dash removed: @param {Object} [parameters] - A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding.

  The doc comments can get a bit complex when you start adding types and names and descriptions. Consider the following: @param {Object} parameters A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding. Once the documentation is generated, this looks nice. But when reading the code, this can be a bit difficult to read. Attached find a patch that enables a dash between the name and the description. Like the following: @param {Object} [parameters] - A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding. The dash is only removed when it appears on the same line as the name. For example, this tag would not have the dash removed: @param {Object} [parameters] - A hash representing connections between this controllers exposed bindings and the global context as well as any default parameters. Bindings are specified with a key ending in Binding.
• Nov 22, 2009

  issue 269 (The source generation/highlighting isn't very flexible.) reported by j...@metrocat.org   -   Rather than tweak the source for publishSrcHilite.js to change the styles, I'd like to be able to use static files from my template. The attached diff uses code-header.html and code-footer.html from the template static folder. I've added a simple version of these files for files.

  Rather than tweak the source for publishSrcHilite.js to change the styles, I'd like to be able to use static files from my template. The attached diff uses code-header.html and code-footer.html from the template static folder. I've added a simple version of these files for files.
• Nov 22, 2009

  issue 268 (Need a way to define external plugins) commented on by j...@metrocat.org   -   Attached find a diff for main.js that adds a plugins option. The folder will be loaded just like the regular plugins folder.

  Attached find a diff for main.js that adds a plugins option. The folder will be loaded just like the regular plugins folder.
• Nov 22, 2009

  issue 268 (Need a way to define external plugins) reported by j...@metrocat.org   -   I'd like to use an svn:external for jsdoc-toolkit, but that means the plugins and templates can't be located in the jsdoc-toolkit folder. Templates are no problem, but plugins are another matter.

  I'd like to use an svn:external for jsdoc-toolkit, but that means the plugins and templates can't be located in the jsdoc-toolkit folder. Templates are no problem, but plugins are another matter.
• Nov 22, 2009

  issue 237 (ENHANCEMENT: Better support for Class.create style documenta...) commented on by micmath   -   Wish granted: Symbol.js modified and committed in revision 826. The plugin looks handy but I'd prefer you maintained your own work. You (or I if you like) can announce it on the mailing list and I'll happily link to your copy of it from the project website or I can post a copy of the file to the user's group -- whichever you prefer.

  Wish granted: Symbol.js modified and committed in revision 826. The plugin looks handy but I'd prefer you maintained your own work. You (or I if you like) can announce it on the mailing list and I'll happily link to your copy of it from the project website or I can post a copy of the file to the user's group -- whichever you prefer.
• Nov 22, 2009

  r826 (Undo "onConstructorDefined", add check to prevent adding par...) committed by micmath   -   Undo "onConstructorDefined", add check to prevent adding parameters more than once. ( issue #237 )

  Undo "onConstructorDefined", add check to prevent adding parameters more than once. ( issue #237 )
• Nov 22, 2009

  issue 237 (ENHANCEMENT: Better support for Class.create style documenta...) commented on by j...@metrocat.org   -   OK, I should have been a bit more clear. This plug in makes documenting Class.create, Class.extend, and Object.extend automatic without the use of @lends or @constructs. The existing technique requires substantial code changes and does not improve the readability of the code. This plug in also permits documenting the class separately from documenting the constructor, without additional tags. I respect your desire to minimise special casing identifiers (e.g. constructor), so I've reworked the plug in, CoherentPlugin.js to perform its magic in onSymbol. This alleviates the need for onConstructorDefined. The one change to the framework that's still required is the patch to Symbol.js. This prevents adding parameters more than once.

  OK, I should have been a bit more clear. This plug in makes documenting Class.create, Class.extend, and Object.extend automatic without the use of @lends or @constructs. The existing technique requires substantial code changes and does not improve the readability of the code. This plug in also permits documenting the class separately from documenting the constructor, without additional tags. I respect your desire to minimise special casing identifiers (e.g. constructor), so I've reworked the plug in, CoherentPlugin.js to perform its magic in onSymbol. This alleviates the need for onConstructorDefined. The one change to the framework that's still required is the patch to Symbol.js. This prevents adding parameters more than once.
• Nov 22, 2009

  issue 237 (ENHANCEMENT: Better support for Class.create style documenta...) Status changed by micmath   -   It's hard to answer your question, without knowing exactly what your goal is. At one point you said it was to "Document class declarations using the Class.create idiom," and I think I've shown how that can be done. It sounds like your new goal is to have things named 'constructor' automatically get treated as if they had a @constructs tag. There probably isn't anyway to do that without modifying the source code of Walker.js, as that is where there is already some magic being applied to make the @constructs tag work at all. However, as I said, I'd rather not have things named 'constructor' treated in a special way by the documentation generator, that's what the @constructs tag is for: it's more flexible because it can be applied to any function regardless of name, it's already a known and documented way of doing it, and I don't think it's too difficult to add a @constructs tag when documenting a function that will be used as the constructor. For the above reasons I don't want to add any automatic treatment for things named "constructor" to Walker, but it should be possible for anyone else to add a plugin that will layer this behavior on top of the core. To make that possible I added a new hook for the plugin manager, named 'onConstructorDefined' (committed in revision 825). you would register for this by adding a file to the app/plugins folder (named anythingYouWant.js) with some code like this: JSDOC.PluginManager.registerPlugin( "JSDOC.constructor", // name it anything unique, maybe "metrocat.thingy"? { onConstructorDefined: function(doc) { doc.parse(doc.src += "\n@constructs"); } } );

  Status: Fixed

  It's hard to answer your question, without knowing exactly what your goal is. At one point you said it was to "Document class declarations using the Class.create idiom," and I think I've shown how that can be done. It sounds like your new goal is to have things named 'constructor' automatically get treated as if they had a @constructs tag. There probably isn't anyway to do that without modifying the source code of Walker.js, as that is where there is already some magic being applied to make the @constructs tag work at all. However, as I said, I'd rather not have things named 'constructor' treated in a special way by the documentation generator, that's what the @constructs tag is for: it's more flexible because it can be applied to any function regardless of name, it's already a known and documented way of doing it, and I don't think it's too difficult to add a @constructs tag when documenting a function that will be used as the constructor. For the above reasons I don't want to add any automatic treatment for things named "constructor" to Walker, but it should be possible for anyone else to add a plugin that will layer this behavior on top of the core. To make that possible I added a new hook for the plugin manager, named 'onConstructorDefined' (committed in revision 825). you would register for this by adding a file to the app/plugins folder (named anythingYouWant.js) with some code like this: JSDOC.PluginManager.registerPlugin( "JSDOC.constructor", // name it anything unique, maybe "metrocat.thingy"? { onConstructorDefined: function(doc) { doc.parse(doc.src += "\n@constructs"); } } );

  Status: Fixed
• Nov 22, 2009

  r825 (Added new plugin hook named "onConstructorDefined" for funct...) committed by micmath   -   Added new plugin hook named "onConstructorDefined" for functions in object literals named "constructor".

  Added new plugin hook named "onConstructorDefined" for functions in object literals named "constructor".
• Nov 22, 2009

  TagMemberOf (@memberOf) Wiki page edited by micmath   -   Revision r824 Edited wiki page through web user interface.

  Revision r824 Edited wiki page through web user interface.
• Nov 21, 2009

  issue 267 (Link does not resolve inherited methods) commented on by micmath   -   Jeff, I think I got your name wrong in the Changes.txt file. I'll fix that but by which name would you like me to credit you?

  Jeff, I think I got your name wrong in the Changes.txt file. I'll fix that but by which name would you like me to credit you?
• Nov 21, 2009

  issue 267 (Link does not resolve inherited methods) changed by micmath   -   Thank you. This was committed in revision 823.

  Status: Fixed

  Labels: Type-Patch −Type-Enhancement

  Thank you. This was committed in revision 823.

  Status: Fixed

  Labels: Type-Patch −Type-Enhancement
• Nov 21, 2009

  r823 (Applied patch from kunhualqk, fix for bug where @link to bor...) committed by micmath   -   Applied patch from kunhualqk, fix for bug where @link to borrowed member did not resolve to parent class. ( issue #218 )

  Applied patch from kunhualqk, fix for bug where @link to borrowed member did not resolve to parent class. ( issue #218 )
• Nov 21, 2009

  issue 267 (Link does not resolve inherited methods) changed by micmath   -  

  Status: Accepted

  Labels: Type-Enhancement

  Status: Accepted

  Labels: Type-Enhancement
• Nov 21, 2009

  issue 218 (Still getting WARNING: Trying to document ...) commented on by micmath   -   It isn't possible to document the members of a class without also documenting the class. On the other hand if the class is unimportant in your documentation you can tag it as a @namespace, which will simply collect all the members under that name. Of course you still need to add a doc comment to the class in order to mark it as a namespace.

  It isn't possible to document the members of a class without also documenting the class. On the other hand if the class is unimportant in your documentation you can tag it as a @namespace, which will simply collect all the members under that name. Of course you still need to add a doc comment to the class in order to mark it as a namespace.
• Nov 18, 2009

  issue 218 (Still getting WARNING: Trying to document ...) commented on by kunhualqk   -   How can I do if I want to document a class and all it's members in the source but don't publish this class in pages? If I can do this use a simple @private or @ignore tag will much help. So I agree to this Issue

  How can I do if I want to document a class and all it's members in the source but don't publish this class in pages? If I can do this use a simple @private or @ignore tag will much help. So I agree to this Issue
• Nov 16, 2009

  issue 267 (Link does not resolve inherited methods) commented on by j...@metrocat.org   -   I've created a patch that adds this functionality.

  I've created a patch that adds this functionality.
• Nov 16, 2009

  issue 267 (Link does not resolve inherited methods) reported by j...@metrocat.org   -   I'd like the @link tag to resolve inherited methods/properties. Consider the following example: /** @class */ function Base() {} /** Foo */ Base.prototype.foo= function() {} /** @class Child @augments Base */ function Child() {} /** This method calls {@link #foo} */ Child.prototype.bar= function() { this.foo(); } Currently, this will generate a link to foo for Child.html.

  I'd like the @link tag to resolve inherited methods/properties. Consider the following example: /** @class */ function Base() {} /** Foo */ Base.prototype.foo= function() {} /** @class Child @augments Base */ function Child() {} /** This method calls {@link #foo} */ Child.prototype.bar= function() { this.foo(); } Currently, this will generate a link to foo for Child.html.
• Nov 16, 2009

  issue 237 (ENHANCEMENT: Better support for Class.create style documenta...) commented on by j...@metrocat.org   -   Although it's possible to redefine the constructor, the default language behaviour is to expose the original constructor using the field 'constructor'. Therefore, I don't feel that the modification to walker.js is invalid. If you have the following code: function MyClass() {} var m= new MyClass(); The value of m.constructor will be MyClass. Can you recommend a way to implement this behaviour via a plugin?

  Although it's possible to redefine the constructor, the default language behaviour is to expose the original constructor using the field 'constructor'. Therefore, I don't feel that the modification to walker.js is invalid. If you have the following code: function MyClass() {} var m= new MyClass(); The value of m.constructor will be MyClass. Can you recommend a way to implement this behaviour via a plugin?
• Nov 16, 2009

  issue 266 (members mistakenly recognized as static) commented on by jbmikk   -   Maybe you should document that in the wiki page for memberOf. It's not clear that you can do this: @memberOf Something# or this: @memberOf Something. That would probably save a lot of time to users and yourself too. It could even be documented in the Namepaths section.

  Maybe you should document that in the wiki page for memberOf. It's not clear that you can do this: @memberOf Something# or this: @memberOf Something. That would probably save a lot of time to users and yourself too. It could even be documented in the Namepaths section.
• Nov 15, 2009

  issue 169 (Patch: add support for getters/setters (get/set keywords)) Status changed by micmath   -   See http://groups.google.com/group/jsdoc-2/t/c8cd5ae7d4c7320

  Status: WontFix

  See http://groups.google.com/group/jsdoc-2/t/c8cd5ae7d4c7320

  Status: WontFix
• Nov 12, 2009

  r822 (Fix to make secure modules modes parse test file correctly.) committed by micmath   -   Fix to make secure modules modes parse test file correctly.

  Fix to make secure modules modes parse test file correctly.
• Nov 12, 2009

  issue 266 (members mistakenly recognized as static) Status changed by micmath   -   @methodOf Test means static Test.run whereas @methodOf Test# means instance someTest.run

  Status: Invalid

  @methodOf Test means static Test.run whereas @methodOf Test# means instance someTest.run

  Status: Invalid
• Nov 10, 2009

  issue 266 (members mistakenly recognized as static) reported by szegedia   -   What steps will reproduce the problem? 1. Save this code to test.js: (function() { /** * @class yaddayadda * @name Test * @constructor */ exports.Test = function() { /** * @name run * @methodOf Test */ this.run = function() { }; }; })(); 2. run $ ./jsrun.sh -t=templates/jsdoc test.js What is the expected output? What do you see instead? I'd expect the Test.html to document "run" as method on Test that is *not* static. However, it declares it to be static. I don't know how to convince JSDoc that it is not static. What version of the product are you using? On what operating system? JSDoc Toolkit 2.3.2 on Mac OS X 10.6.1 Please provide any additional information below.

  What steps will reproduce the problem? 1. Save this code to test.js: (function() { /** * @class yaddayadda * @name Test * @constructor */ exports.Test = function() { /** * @name run * @methodOf Test */ this.run = function() { }; }; })(); 2. run $ ./jsrun.sh -t=templates/jsdoc test.js What is the expected output? What do you see instead? I'd expect the Test.html to document "run" as method on Test that is *not* static. However, it declares it to be static. I don't know how to convince JSDoc that it is not static. What version of the product are you using? On what operating system? JSDoc Toolkit 2.3.2 on Mac OS X 10.6.1 Please provide any additional information below.
• Nov 09, 2009

  issue 249 (NamespaceOf) commented on by brian.brianschweitzer   -   It doesn't now, but yes, that'd be the right idea. (Or NamespaceOf could also be a shortcut to namespace+memberOf, ala methodOf).

  It doesn't now, but yes, that'd be the right idea. (Or NamespaceOf could also be a shortcut to namespace+memberOf, ala methodOf).
• Nov 09, 2009

  issue 265 (Support for @return with properties (same as @param)) changed by micmath   -   Given the existing syntax of: @return {returnType} returnDescription Your proposal is probably impossible to make backwards compatible, because it is not possible to distinguish between the [name of the return value] and [the first words of the description]. @return {Stuff} Objects that have stuff. @return {Stuff} Objects.Or some other things. You can accomplish what you want with existing tags though, you can either describe the return value properties in the returnDescription directly, or you can document a class for the returned object like this: /** @class @name UriInformation @property {String} hostName @property {Integer} portNumber */ /** @name getUriInformation @function @returns {UriInformation} */

  Status: WontFix

  Labels: Type-Enhancement

  Given the existing syntax of: @return {returnType} returnDescription Your proposal is probably impossible to make backwards compatible, because it is not possible to distinguish between the [name of the return value] and [the first words of the description]. @return {Stuff} Objects that have stuff. @return {Stuff} Objects.Or some other things. You can accomplish what you want with existing tags though, you can either describe the return value properties in the returnDescription directly, or you can document a class for the returned object like this: /** @class @name UriInformation @property {String} hostName @property {Integer} portNumber */ /** @name getUriInformation @function @returns {UriInformation} */

  Status: WontFix

  Labels: Type-Enhancement
• Nov 09, 2009

  issue 265 (Support for @return with properties (same as @param)) reported by bkonetzny   -   As many functions return an object as an result, it would be nice to document them like we can document the parameters. Example - My function returns an object with 2 properties: @return {Object} UriInformation @return {String} UriInformation.hostName @return {Integer} UriInformation.portNumber

  As many functions return an object as an result, it would be nice to document them like we can document the parameters. Example - My function returns an object with 2 properties: @return {Object} UriInformation @return {String} UriInformation.hostName @return {Integer} UriInformation.portNumber
• Nov 08, 2009

  LinkLove (Who's using or talking about JsDoc.) Wiki page edited by micmath   -   Revision r821 Edited wiki page through web user interface.

  Revision r821 Edited wiki page through web user interface.
• Nov 08, 2009

  issue 261 (All @namespace fields & methods are marked static) commented on by ekaynelson   -   Thanks for confirming that this is intended behavior. There's now some disagreement now on my team about whether fully-qualified names are desirable or not, so I'll have to pin that down before I figure out what to do. You're right -- when that debate is settled, I'll look at the template to see if I can figure out how to output only short (not fully-qualified) names for static fields. Thanks again. Your help is always much appreciated. Elizabeth

  Thanks for confirming that this is intended behavior. There's now some disagreement now on my team about whether fully-qualified names are desirable or not, so I'll have to pin that down before I figure out what to do. You're right -- when that debate is settled, I'll look at the template to see if I can figure out how to output only short (not fully-qualified) names for static fields. Thanks again. Your help is always much appreciated. Elizabeth