jsdoc-user Mailing List for JSDoc (Page 9)
Status: Inactive
Brought to you by:
mmathews
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(16) |
Oct
(2) |
Nov
(7) |
Dec
(10) |
2006 |
Jan
(7) |
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(7) |
Sep
(5) |
Oct
(19) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
(3) |
Mar
(31) |
Apr
(10) |
May
(7) |
Jun
(9) |
Jul
(2) |
Aug
(5) |
Sep
(1) |
Oct
(6) |
Nov
(3) |
Dec
(2) |
2008 |
Jan
|
Feb
(7) |
Mar
(1) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(16) |
Oct
(7) |
Nov
(24) |
Dec
(34) |
2009 |
Jan
(9) |
Feb
(13) |
Mar
(14) |
Apr
(25) |
May
(35) |
Jun
(20) |
Jul
(33) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
2010 |
Jan
(12) |
Feb
(7) |
Mar
(4) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Max d'A. <ma...@da...> - 2005-12-21 18:03:55
|
Hello Gabriel. Looking at the latest 1.9.7 version I noticed the following minor error with stylesheet.css: /* Font used in left-hand frame lists */ .FrameTitleFont { font-size: 10pts; font-family: Helvetica, Arial, san-serif } .FrameHeadingFont { font-size: 10pts; font-family: Helvetica, Arial, san-serif } .FrameItemFont { font-size: 10pts; font-family: Helvetica, Arial, san-serif } the font-size should be "pt" rather than "pts". ================================================= Looking at Constant value I have a couple of questions. 1. It would be nice if there was a link in the bottom left window showing "All Classes" to the "Constant Field Values" page. At the moment the only way I can find of getting there is to find a constant value and then click on the link to the page. 2. When prototype properties are flagged as "@final" they don't show up on the Constant Field Values page. Here is an example. function MyObject() { // Constructor function. } /** Constant prototype number, value = 10. This doesn't get documented on the Constants page, although the Field Details do have a link to the Constant Field Values page. @final */ MyObject.prototype.constant_prototype_number = 10; /** Constant number, value = 20. This gets documented in the Constant Field Values page. @final */ MyObject.constant_number = 20; Regards Max |
From: Sergio P. <ser...@us...> - 2005-12-21 01:10:37
|
Please forgive me if this has already been answered before. I am new to = this group. I was trying to figure out how to show that the subclassed = object is in another file and when the user clicks that object it clicks = to the other file. So here is how my files look =20 File A: function _Class1() { this.Class2=3D _ Class2(); } =20 =20 File B: function _ Class2() { this.Class2Method =3D function () { //statement here } } =20 Class1. Class2.FileBMethod() =20 How can I show this relationship with JSDOC. I can't seem to figure this = out. Hope this makes sense? =20 Sergio Pi=F1on Senior Software Engineer Information Technology Department G4S Justice Services Inc. 30201 Aventura Rancho Santa Margarita, CA 92688 Tel: (949) 635-1600 x325 Fax: (949) 635-1614 ser...@us... <mailto:ser...@us...>=20 =20 This company is part of the Group 4 Securicor group of companies. This = communication contains information which may be confidential, personal = and/or privileged. It is for the exclusive use of the intended = recipient(s). If you are not the intended recipient(s), please note that = any distribution, forwarding, copying or use of this communication or = the information in it is strictly prohibited. Any personal views = expressed in this e-mail are those of the individual sender and the = Company does not endorse or accept responsibility for them. Prior to = taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This message has been = checked for viruses on behalf of the Company. =20 |
From: Gabriel R. <gab...@gm...> - 2005-12-18 18:37:38
|
On Thu, Dec 01, 2005 at 10:38:08PM +1300, Adam Ratcliffe wrote: > Hi, > > I seem to have come up against some limitations in using the @link > and @see tags. This issue has been resolved in the newly-released version 1.9.7 of JSDoc. Gabriel |
From: Adam R. <ad...@pr...> - 2005-12-07 21:33:11
|
Hi Gabriel Looking forward to the new release :) Cheers Adam On 8 Dec, 2005, at 8:35 AM, Gabriel Reid wrote: > On Thu, Dec 01, 2005 at 10:38:08PM +1300, Adam Ratcliffe wrote: >> I seem to have come up against some limitations in using the @link >> and @see tags. >> >> Firstly I don't seem to be able to link to 'static' methods with >> these tags, for example: >> >> function foo() {} >> >> /** >> * @see #baz >> */ >> foo.bar = function() { >> // do something >> }; >> >> foo.baz = function() { >> // do something else >> } >> >> Secondly, I can't link to a class constant variable such as: >> >> /** >> * @final >> * @type String >> */ >> foo.MY_CONST = "my constant value"; >> >> Is there a way to reference these members with jsdoc? > > Sorry for taking so long to respond to this. Both of these problems > are > unfortunate side-effects of a recent fix that was made to linking of > static members. It will be fixed in the next release of JSDoc, > hopefully > within a week from now. Thanks for reporting this. > > Gabriel > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Jsdoc-user mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdoc-user > > |
From: Gabriel R. <gab...@gm...> - 2005-12-07 19:38:25
|
On Thu, Dec 01, 2005 at 10:38:08PM +1300, Adam Ratcliffe wrote: > I seem to have come up against some limitations in using the @link > and @see tags. > > Firstly I don't seem to be able to link to 'static' methods with > these tags, for example: > > function foo() {} > > /** > * @see #baz > */ > foo.bar = function() { > // do something > }; > > foo.baz = function() { > // do something else > } > > Secondly, I can't link to a class constant variable such as: > > /** > * @final > * @type String > */ > foo.MY_CONST = "my constant value"; > > Is there a way to reference these members with jsdoc? Sorry for taking so long to respond to this. Both of these problems are unfortunate side-effects of a recent fix that was made to linking of static members. It will be fixed in the next release of JSDoc, hopefully within a week from now. Thanks for reporting this. Gabriel |
From: Adam R. <ad...@pr...> - 2005-12-01 09:38:26
|
Hi, I seem to have come up against some limitations in using the @link and @see tags. Firstly I don't seem to be able to link to 'static' methods with these tags, for example: function foo() {} /** * @see #baz */ foo.bar = function() { // do something }; foo.baz = function() { // do something else } Secondly, I can't link to a class constant variable such as: /** * @final * @type String */ foo.MY_CONST = "my constant value"; Is there a way to reference these members with jsdoc? Kind regards Adam |
From: Gabriel R. <gab...@gm...> - 2005-11-20 21:24:12
|
Hi, > > a long story short: hopefully I'll release in the next day or two (or > > maybe even in the next hour or two). > > good news! looking forward to the release, but no hurries. As you've maybe already seen, the new version was released a couple of days ago (I'm just a bit behind in handling e-mail....) > > Yes, this is another one of those things that is really difficult (or > > impossible) to get right to satisfy everyone. The far-away plan for > > JSDoc is to rewrite it in Java using Rhino, and then just let Rhino > > decide what's what instead of me trying to fish it out with regular > > expressions :) > > well, we are working with java *and* rhino and as i already said we really need a good and meaningful javascript documentation feature. (certainly, a java version of jsdoc would be much more valuable for us than the perl one -- no matter how excellent it already is.) do you think we could join our forces here? Well, there are still some issues that I'm thinking about with all of this, not to mention the fact that putting aside enough time to really think all of this through is proving to be a challenge in itself :( However, in any case I'm interested in going towards a version based around a real parser, and java/rhino certainly looks like the best way to go. Once things do start moving in that direction, help will certainly be appreciated! > btw. i found some more issues; do you want me to report them as bugs immediately or is it ok if i post them here again? Well, either is ok, although it's nice to have them actually logged in the bug-reporting system so I don't forget about them. Actually, what's nicest is if they're reported in the bug-reporting system AND posted in this list, but I realize that takes more time and effort, so just do what you've got time/energy for. Gabriel |
From: <tob...@or...> - 2005-11-18 09:42:12
|
hi gabriel > a long story short: hopefully I'll release in the next day or two (or > maybe even in the next hour or two). =20 good news! looking forward to the release, but no hurries. > I suppose the main thing I'm not sure about is if this should just > become default behaviour or not. If it does just become default > behaviour, there's definitely a lot of potential for it to be a real > annoyance to existing users, so it might be introduced as a > command-line option, or global variables that are to be documented > could have to be marked with a @global tag or something like that. > Any other suggestions? =20 i consider a command-line option the best solution but i would be fine = with the @global tag as well. you know your established user community = best; thus, you will make the right decision to avoid breaking something = for them anyway. =20 > Yes, this is another one of those things that is really difficult (or > impossible) to get right to satisfy everyone. The far-away plan for > JSDoc is to rewrite it in Java using Rhino, and then just let Rhino > decide what's what instead of me trying to fish it out with regular > expressions :) =20 well, we are working with java *and* rhino and as i already said we = really need a good and meaningful javascript documentation feature. = (certainly, a java version of jsdoc would be much more valuable for us = than the perl one -- no matter how excellent it already is.) do you = think we could join our forces here? btw. i found some more issues; do you want me to report them as bugs = immediately or is it ok if i post them here again? ciao, tobi |
From: Gabriel R. <gab...@gm...> - 2005-11-16 20:37:32
|
Hi, > btw. when do you plan to release the next version of JSDoc? Well, I was actually just about to release it yesterday evening, and then I noticed that a bunch of the unit tests were failing. It looks like this is just related to changes in the behaviour of the preprocessor and probably nothing is really broken, so I just have to go through and double-check all of that before I release it. To make a long story short: hopefully I'll release in the next day or two (or maybe even in the next hour or two). > > For the moment, global variables like this are simply ignored. > > There's been talk of adding a '@global' tag or something similar to > > tell JSDoc to add these to the global class, but I haven't > > implemented it yet. I'd say it's coming, but I can't say when > > exactly. > > is there a pointer to follow this discussion? it's just that i cannot > think of any good reason at all why such globals should be excluded > from a documentation... I just checked, and this has been entered as a request on SourceForge. You can view the issue at <http://sourceforge.net/tracker/index.php?func=detail&aid=1239787&group_id=30801&atid=400647>. I suppose the main thing I'm not sure about is if this should just become default behaviour or not. If it does just become default behaviour, there's definitely a lot of potential for it to be a real annoyance to existing users, so it might be introduced as a command-line option, or global variables that are to be documented could have to be marked with a @global tag or something like that. Any other suggestions? > > If two versions of function bar are in the same scope as shown above, > > only one of them will be available at execution. JSDoc can also only > > handle a single version of a function with a given name, although I > > believe JSDoc will take the first version it find, as opposed to a JS > > interpreter, which will take the last. Or am I missing something? > > nope, you're totally right. this is kind of a speciality of hop, the > application server we are using. script files are located in > directories which determine the prototype (or class) they belong to. > this way, we can define a method bar() in two (or more) directories, > say Foo and FooBar, and make them instance methods of different > prototypes. (it's not really good practice anymore and we are > currently elaborating on that, anyway). > > but i don't want to bother you with such details. it's just that i > thought it would feel natural if JSDoc was to take the @member tag with > a higher priority and document a method according to it -- just as it > takes e.g. @extend simply as is without further checking if there really > is such a parent class... Yes, this is another one of those things that is really difficult (or impossible) to get right to satisfy everyone. The far-away plan for JSDoc is to rewrite it in Java using Rhino, and then just let Rhino decide what's what instead of me trying to fish it out with regular expressions :) Regards, Gabriel |
From: <sch...@ma...> - 2005-11-16 12:13:58
|
> nope, you're totally right. this is kind of a speciality of hop, the > application server we are using. script files are located in > directories which determine the prototype (or class) they belong to. > this way, we can define a method bar() in two (or more) directories, > say Foo and FooBar, and make them instance methods of different > prototypes. (it's not really good practice anymore and we are > currently elaborating on that, anyway). > > but i don't want to bother you with such details. it's just that i > thought it would feel natural if JSDoc was to take the @member tag with > a higher priority and document a method according to it -- just as it > takes e.g. @extend simply as is without further checking if there really > is such a parent class... Same goes for us, a example: er have applications in folders organized like: applications/app/em01/em01.xul applications/app/em02/em01.js applications/app/em02/em02.xul applications/app/em02/em02.js each xul file has a script tag like <script src=""em01.js" /> while each js page contains our so called controller (getting vars fromthe ui and sticking them into apis) em01.js function FXPAGE() { } FXPAGE.prototype.load() { } .... So we could use that too. btw: last tip for own @tags worked well. Greets Sebastian ----------------------------------------------------------------------------- - Mayflower GmbH - http://www.mayflower.de - E-Mail: in...@ma... - |
From: <tob...@or...> - 2005-11-16 10:33:19
|
hi gabriel thanks for your quick reply. > I've just fixed this problem, thanks for reporting it. A while back I > added a step in the preprocessor to shrink down all string literals > to avoid problems that were occurring with segfaults in some builds > of perl, without noticing that it broke this functionality. I've > removed that preprocessor step, as I'm now encouraging people to get > a build of perl that doesn't segfault on recursive regexes instead of > trying to work around it in JSDoc. great! i certainly encourage you to avoid fixing other people's bugs. (but sometimes it just has to be :) btw. when do you plan to release the next version of JSDoc? > For the moment, global variables like this are simply ignored. > There's been talk of adding a '@global' tag or something similar to > tell JSDoc to add these to the global class, but I haven't > implemented it yet. I'd say it's coming, but I can't say when > exactly. is there a pointer to follow this discussion? it's just that i cannot=20 think of any good reason at all why such globals should be excluded=20 from a documentation... > If two versions of function bar are in the same scope as shown above, > only one of them will be available at execution. JSDoc can also only > handle a single version of a function with a given name, although I > believe JSDoc will take the first version it find, as opposed to a JS > interpreter, which will take the last. Or am I missing something? nope, you're totally right. this is kind of a speciality of hop, the=20 application server we are using. script files are located in=20 directories which determine the prototype (or class) they belong to.=20 this way, we can define a method bar() in two (or more) directories,=20 say Foo and FooBar, and make them instance methods of different=20 prototypes. (it's not really good practice anymore and we are=20 currently elaborating on that, anyway). but i don't want to bother you with such details. it's just that i=20 thought it would feel natural if JSDoc was to take the @member tag with=20 a higher priority and document a method according to it -- just as it=20 takes e.g. @extend simply as is without further checking if there really = is such a parent class... ciao, tobi ps. sorry for the list-inadequate layout of my first e-mail... i hope this one's better now. |
From: Gabriel R. <gab...@gm...> - 2005-11-15 20:28:32
|
On Tue, Nov 15, 2005 at 01:25:09PM +0100, tob...@or... wrote: > first of all, congrats for this great tool. i am very delighted using jsdoc with javascript code and cannot think of working without the resulting api docs anymore. > > if i might introduce myself shortly: i am a developer at the online branch of austrian broadcast station ORF [1]. we are using and developing a java-based, open-source application server called HOP (or helma object publisher) [2] which incorporates rhino [3] to enable us writing the production code in ecmascript. > Thanks for the info about how you're using JSDoc. It's always nice to hear things like this :) > 1. string constants (marked with the @final tag) do not appear in a meaningful way on the page of "constant field values" (see attached screenshot). i expected to see the actual string value, instead all i get is a cryptic "s"... > > the code causing the "duplo.TEST" entry is here: > > /** > * @final > */ > duplo.TEST = "Hello, World!"; I've just fixed this problem, thanks for reporting it. A while back I added a step in the preprocessor to shrink down all string literals to avoid problems that were occurring with segfaults in some builds of perl, without noticing that it broke this functionality. I've removed that preprocessor step, as I'm now encouraging people to get a build of perl that doesn't segfault on recursive regexes instead of trying to work around it in JSDoc. > > 2. i wondered a lot about what happens to global fields, ie. variables which aren't assigned a function but a "simple" value, like: > > /** > * @type Number > */ > var globalVariable = 123; > > it does not show up anywhere in the jsdoc-generated output but actually, i expect it to become a field in GLOBALS (or whatever name i choose with the --globals-name argument). > For the moment, global variables like this are simply ignored. There's been talk of adding a '@global' tag or something similar to tell JSDoc to add these to the global class, but I haven't implemented it yet. I'd say it's coming, but I can't say when exactly. > > 3. if i am using a function name twice, once globally and another time for a class method, one of them is left out in the docs. e.g. > > function bar() { > return 123; > } > > /** > * @constructor > */ > function Foo() { > } > > /** > * @member Foo > */ > function bar() { > return "abc"; > } > > i expected to find bar() twice in the generated index, once as method of the Foo class, and once as global function. but all i get is documentation about the class method. > If two versions of function bar are in the same scope as shown above, only one of them will be available at execution. JSDoc can also only handle a single version of a function with a given name, although I believe JSDoc will take the first version it find, as opposed to a JS interpreter, which will take the last. Or am I missing something? Thanks a lot for using JSDoc, as well as posting to the list. If there's anything else, just let me know. Regards, Gabriel |
From: <tob...@or...> - 2005-11-15 12:25:16
|
hi there first of all, congrats for this great tool. i am very delighted using = jsdoc with javascript code and cannot think of working without the = resulting api docs anymore. if i might introduce myself shortly: i am a developer at the online = branch of austrian broadcast station ORF [1]. we are using and = developing a java-based, open-source application server called HOP (or = helma object publisher) [2] which incorporates rhino [3] to enable us = writing the production code in ecmascript. so we produce pretty a lot of javascript code and thus, my colleages and = me are very interested in good documentation -- like the one jsdoc = provides. thus, we are really keen on extensively using jsdooc for our basic = documentation. however, i just noticed some (minor) things troubling us = and i wanted to let you know about them: 1. string constants (marked with the @final tag) do not appear in a = meaningful way on the page of "constant field values" (see attached = screenshot). i expected to see the actual string value, instead all i = get is a cryptic "s"... the code causing the "duplo.TEST" entry is here: /** * @final */ duplo.TEST =3D "Hello, World!"; 2. i wondered a lot about what happens to global fields, ie. variables = which aren't assigned a function but a "simple" value, like: /** * @type Number=20 */ var globalVariable =3D 123; it does not show up anywhere in the jsdoc-generated output but actually, = i expect it to become a field in GLOBALS (or whatever name i choose with = the --globals-name argument). 3. if i am using a function name twice, once globally and another time = for a class method, one of them is left out in the docs. e.g. function bar() { return 123; } /** * @constructor */ function Foo() { } /**=20 * @member Foo */ function bar() { return "abc"; } i expected to find bar() twice in the generated index, once as method of = the Foo class, and once as global function. but all i get is = documentation about the class method. hopefully, i am not stating anything obvious or redundant (actually, i = took a look through the bug reports and mailing-list messages but might = have missed something). moreover, i hope you find this information valuable and probably can = solve these issues. best regards, tobi -- [1] http://orf.at [2] http://helma.org [3] http://www.mozilla.org/rhino/ |
From: Gabriel R. <gab...@gm...> - 2005-10-31 08:53:06
|
On Thu, Oct 27, 2005 at 05:12:56PM +0200, sch...@ma... wrote: > Hi we use a adapter in js/xul to server, that gives us results of > cobol methods. > These data is stored in meber classes noted like > > MY_CLASS.pprototype.basic = { > a: '', > b: '', > c: '' > } > > MY_CLASS.pprototype.set_basic = function(data){ > > } > > coming from cobol method get_basic So far all this methods are > accessible via a web iterface, describing all in & output data > structures. i just need to add following tag to the document > > @cobol get_basic > > and i need a <a > href="http://mysite.com/dd/index.php?method=get_basic">Cobolmethdod: > get_basic</a> Adding the following segment to the .jsdoc_config file should do the trick: ############################################################################## $METHOD_ATTRS_MAP{cobol} = sub { "Cobol method: <a href='http://mysite.com/dd/index.php?method=" . $_[0][0] . "'>" . $_[0][0] . "</a>"; }; ############################################################################## That will add a link to the method description (of the method where the @cobol tag is used). By the way, if you don't mind (and are allowed) to tell a bit more about the JavaScript/Cobol link, I'd certainly be interested in hearing more about it! Gabriel |
From: <sch...@ma...> - 2005-10-26 17:01:00
|
Hi I need to add a own tag. (@cobol) Where must i get my hands on ? Is there a hint i can get. Thanks in advance Sebastian ----------------------------------------------------------------------------- ++ Besuchen Sie uns auf der Systems in der MySQL-Area, Halle 3, Stand 162 und gewinnen Sie einen von drei Apple i-Pod Nano bei unserer Messe-Verlosung ++ |
From: Max d'A. <ma...@da...> - 2005-09-19 09:17:41
|
Just tried the version 1.9.5.8 and it works fine for me now. The speedy bug fix service is much appreciated. Thanks, Max |
From: Gabriel R. <gab...@gm...> - 2005-09-18 14:14:39
|
> Interestingly, if I move the first three function/method/getter > declarations below the next set of declarations they don't get > documented, but the new first three do. > > The other getter declarations aren't being documented, so I guess the > problem may stem from the code handling this. Okay, this is taken care of in version 1.9.5.8, which has just been released. Thanks again for reporting it. Gabriel |
From: Gabriel R. <gab...@gm...> - 2005-09-18 13:26:29
|
On Sun, Sep 18, 2005 at 11:22:12AM +0100, Max d'Ayala wrote: > Sorry, I seem to have sent that last meesage just to you when I meant to > send it to the list as well. > > Anyway, attached is the file I am trying to document. > > Interestingly, if I move the first three function/method/getter > declarations below the next set of declarations they don't get > documented, but the new first three do. > > The other getter declarations aren't being documented, so I guess the > problem may stem from the code handling this. > Hmm, strange. I'll try to get this sorted and released this evening. Thanks a lot for re-reporting this, and sending the code sample. Regards, Gabriel |
From: Gabriel R. <gab...@gm...> - 2005-09-17 19:12:11
|
On Fri, Sep 16, 2005 at 10:35:28PM +0100, Max d'Ayala wrote: > Hello, I've just started trying out JSDoc and have a few questions if > anyone can answer them. > > 1. There appears to be a minor bug if you include a single quote > (apostrophe) in inline comments using a double slash. > E.g. a line such as; > myFunction(); //This is today's test code. > > When I look at the "File" page the source code highlighting breaks at > the single quote. (I think it starts again if you hit another single > quote in another inline comment.) I've just released a new version (1.9.5.7) with this fixed. > 3. I seem to be having problems with Mozilla style getters and setters > not being documented. This is also fixed in 1.9.5.7. Thanks for reporting these bugs. Regards, Gabriel |
From: Gabriel R. <gab...@gm...> - 2005-09-17 06:41:02
|
> 1. There appears to be a minor bug if you include a single quote > (apostrophe) in inline comments using a double slash. > E.g. a line such as; > myFunction(); //This is today's test code. > > When I look at the "File" page the source code highlighting breaks at > the single quote. (I think it starts again if you hit another single > quote in another inline comment.) > I've just noticed a bug that seems to occur when inline comments are included on the same line as code. Could you either send me (or the list) a complete (but preferably small) JavaScript source file that demonstraes this? I'll plan to release a fixed version this weekend. > > 2. Are the * characters optional at the start of lines within the > special comment blocks? Yes, they are. > > 3. I seem to be having problems with Mozilla style getters and setters > not being documented. > > E.g. > > Element.prototype.__defineGetter__( > "getSomething", > function() > { > var temp = this.aproperty; > return temp; > } > ); > This is *supposed* to work, but having just checked it as well, I've seen that it doesn't work anymore. I'll have this fixed as well in the release this weekend. Thanks for pointing these bugs out! Regards, Gabriel |
From: Max d'A. <ma...@da...> - 2005-09-16 21:33:02
|
Hello, I've just started trying out JSDoc and have a few questions if anyone can answer them. 1. There appears to be a minor bug if you include a single quote (apostrophe) in inline comments using a double slash. E.g. a line such as; myFunction(); //This is today's test code. When I look at the "File" page the source code highlighting breaks at the single quote. (I think it starts again if you hit another single quote in another inline comment.) 2. Are the * characters optional at the start of lines within the special comment blocks? 3. I seem to be having problems with Mozilla style getters and setters not being documented. E.g. Element.prototype.__defineGetter__( "getSomething", function() { var temp = this.aproperty; return temp; } ); I've tried several combinations of @ commands without success. Is this a type of javascript expression that is too complicated to be picked up? Many thanks for any answers. Regards Max I'm using the latest version of JSDoc (1.9.5.6) on a Windows Me platform if that makes any difference. |
From: EventListener <eve...@gm...> - 2005-09-16 17:59:04
|
What I neglected to mention is that I am actually "inheriting" functions=20 from the "superclass" which is very handy since it effectively allows me to override only selecte= d=20 functions. Example =3D Class.create(); Example.prototype =3D Object.extend( new ExampleSuperClass(), { /** This comment isn't found */ initialize: function() { } } JSDoc is such a nice documentation tool -- if there is a way to add support= =20 for this, even with manual @ tags, I'll take it. I don't know PERL so I=20 haven't had luck playing with your regex's. As far as a general way of tagging this type of thing -- would it be=20 possible to provide a sort of "ignore the structure" tag that says this=20 thing here is a function no matter what surrounds it? like (thinking that this could be put anywhere in the code?): /** This is my weird function construct @forceDocumentation @functionName myFunction @className MyClass */ This would be useful with prototype.js in two ways: 1. for the Object.extend() method 2. to allow documentation of the constructor that is buried by Class.create () Is something like this possible? Thanks, Cathy On 9/16/05, Gabriel Reid <gab...@gm...> wrote: >=20 > On Thu, Sep 15, 2005 at 06:01:07PM -0700, EventListener wrote: > > I am using the prototype.js library to extend Objects. > > Any suggestions on how to get methods declared like this to show up in= =20 > the > > documentation? > > > > Here is an example of what I'm doing: > > > > Example =3D Class.create(); > > Example.prototype =3D Object.extend( new Example(), { > > > > /** > > This comment isn't found > > */ > > initialize: function() > > { > > > > } > > } >=20 > At the moment, there isn't a way of getting JSDoc to recognize this kind > of construct (at least, as far as I'm aware). JSDoc can't "understand" > what's going on here, because it's actually just an anonymous definition > where the initialize function is declared. >=20 > I've just looked at the prototype.js code, and noticed that the > Object.extend method simply copies all properties from the second > argument into the first argument. As a result, the above code could be > written as follows, with (I believe) the same result: >=20 >=20 > Example =3D Class.create(); > Example.prototype =3D { >=20 > /** > This comment is found > */ > initialize: function() > { >=20 > } > }; >=20 > The above code will be correctly recognized by JSDoc. >=20 > Unfortunately, support for things as dynamic as what you originally > posted just isn't available right now. If it were to be supported, it > would have to be done purely with '@' tags. If you've got some > suggestions on how this could be done in a general manner (from the > point of view of the actual documentation in the JavaScript code), > please let me know. >=20 > Regards, >=20 > Gabriel > |
From: Gabriel R. <gab...@gm...> - 2005-09-16 17:40:16
|
On Thu, Sep 15, 2005 at 06:01:07PM -0700, EventListener wrote: > I am using the prototype.js library to extend Objects. > Any suggestions on how to get methods declared like this to show up in the > documentation? > > Here is an example of what I'm doing: > > Example = Class.create(); > Example.prototype = Object.extend( new Example(), { > > /** > This comment isn't found > */ > initialize: function() > { > > } > } At the moment, there isn't a way of getting JSDoc to recognize this kind of construct (at least, as far as I'm aware). JSDoc can't "understand" what's going on here, because it's actually just an anonymous definition where the initialize function is declared. I've just looked at the prototype.js code, and noticed that the Object.extend method simply copies all properties from the second argument into the first argument. As a result, the above code could be written as follows, with (I believe) the same result: Example = Class.create(); Example.prototype = { /** This comment is found */ initialize: function() { } }; The above code will be correctly recognized by JSDoc. Unfortunately, support for things as dynamic as what you originally posted just isn't available right now. If it were to be supported, it would have to be done purely with '@' tags. If you've got some suggestions on how this could be done in a general manner (from the point of view of the actual documentation in the JavaScript code), please let me know. Regards, Gabriel |
From: EventListener <eve...@gm...> - 2005-09-16 01:01:15
|
I am using the prototype.js library to extend Objects. Any suggestions on how to get methods declared like this to show up in the= =20 documentation? Here is an example of what I'm doing: Example =3D Class.create(); Example.prototype =3D Object.extend( new Example(), { /** This comment isn't found */ initialize: function() { } } Thanks, Cathy |
From: EventListener <eve...@gm...> - 2005-09-16 00:56:37
|
Examplet =3D Class.create(); Example.prototype =3D Object.extend( new WRScrollLayout(), { /** initialize: function() { }, |