|
From: silvioprog <sil...@gm...> - 2015-06-27 14:59:28
|
Hello,
I'm using PasDoc to generate the documentation of my new framework, and I'm
very happy, because PasDoc is a great tool, generating the documentation
from a code that compiles with Free Pascal and Delphi. Nice! =)
However, in some situations, I have a long comment in the source, and it
disrupts the maintenance of the source, e.g:
[code]
{
Copyright (C) 2015 Brook developers.
This file is part of "Brook framework".
See the file LICENSE.txt, included in this distribution,
for details about the copyright.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
----------------------------------------------------------------------------
}
{ @abstract(Provides root objects for the Brook framework.)
@author(Silvio Clecio - <sil...@gm...>)
@author(Luciano Souza - <luc...@gm...>) }
unit Brook.Lang;
{$I Brook.Lang.inc}
interface
uses
{$IFNDEF FPC}
Windows,
{$ENDIF}
SysUtils;
type
{ @abstract(The root object of the Brook class hierarchy.) }
TBrookObject = class(TObject)
public
{ Creates an instance of its class. }
constructor Create; virtual;
{ Returns the class's unit name concatenated with the class name.
Example:
@longCode(#
begin
WriteLn(TBrookObject.QualifiedClassName); // displays
Brook.Lang.TBrookObject
...
#)}
class function QualifiedClassName: string;
...
[/code]
So, what do you think to use something like this:
Content of "Copyright.txt" (in a folder like "../Docs/TXT"):
*Copyright (C) 2015 Brook developers.*
*This file is part of "Brook framework".*
*See the file LICENSE.txt, included in this distribution,*
*for details about the copyright.*
*This library is distributed in the hope that it will be useful,*
*but WITHOUT ANY WARRANTY; without even the implied warranty of*
*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.*
Content of "Authors.txt":
*@abstract(Provides root objects for the Brook framework.)*
*@author(Silvio Clecio - <sil...@gm... <sil...@gm...>>)*
*@author(Luciano Souza - <luc...@gm... <luc...@gm...>>)*
Content of "TBrookObject.QualifiedClassName.txt":
*Returns the class's unit name concatenated with the class name. Example:*
* @longCode(#*
* begin*
* WriteLn(TBrookObject.QualifiedClassName); // displays
Brook.Lang.TBrookObject*
* ...*
* #)*
So, using this files and a @file tag, I could use it as:
{ @file "Copyright.txt" }
{ @file "Authors.txt" }
unit Brook.Lang;
{$I Brook.Lang.inc}
interface
uses
{$IFNDEF FPC}
Windows,
{$ENDIF}
SysUtils;
type
{ @abstract(The root object of the Brook class hierarchy.) }
TBrookObject = class(TObject)
public
{ @file }
class function QualifiedClassName: string;
Using this command:
$ pasdoc --doc-source-path=../Doc/TXT/ ...
Or, to use without the extra param above:
{ @file "../Doc/TXT/TBrookObject.QualifiedClassName.txt" }
class function QualifiedClassName: string;
Or:
{ @dir "/Docs/TXT/" }
{ @file "Copyright.txt" }
{ @file "Authors.txt" }
unit Brook.Lang;
{$I Brook.Lang.inc}
{ @file "TBrookObject.QualifiedClassName.txt" }
class function QualifiedClassName: string;
Or:
{ @file }
class function QualifiedClassName: string;
@dir Specify the default directory used by @file tag.
@file Specify a file wich will used as documentation.
You can use "@file 'your-doc.file.txt'" or "@file", this last option will
search the file containing the class and method name like
"TMyClass.MyMethod.txt" in current directory or specified via @dir.
Is it an good idea or I'm daydreaming? =/
Thank you!
--
Silvio Clécio
My public projects - github.com/silvioprog
|
|
From: Michalis K. <mic...@gm...> - 2015-08-09 00:47:01
|
silvioprog wrote: > You can use "@file 'your-doc.file.txt'" or "@file", this last option > will search the file containing the class and method name like > "TMyClass.MyMethod.txt" in current directory or specified via @dir. > > Is it an good idea or I'm daydreaming? =/ > (Sorry for such delay in answering! Busy times....) Basically, I see that most of your use-cases are covered by the @include tag, that allows to include a description from a specified file. See http://pasdoc.sipsolutions.net/IncludeTag . This basically does what your @file option would do. And to avoid having to write @include... tag too often, you can use --description command-line option, see http://pasdoc.sipsolutions.net/ReadDescriptionFromFile . This allows to place (multiple) descriptions in an external file, and they will be automatically used by PasDoc. So, some of needs are already implemented:) What is missing is the automatic guessing of filename to include. That is, in your proposal, one can write @file without a parameter, and then the name of the file is automatically guessed from the identified name. I think that this can be implemented as just an extension of @include tag? When the parameters are empty, then guess the file name. The contributions are most welcome:) In your proposal, you also add command-line options and tags to specify the directory where to look for files. These seem like good ideas to organize descriptions, I only have small notes: 1. --doc-source-path= should rather be --include-doc-dir= or such? Just keep "include" in the name, to make it clear it's used with @include. 2. For similar reasons, @dir tag should be called @includeDocDir . Keep the phrase "include" inside. 3. The effect of @includeDocDir should only apply to the current unit. Otherwise parsing order, command-line order, cache may all cause problems. Best regards! Michalis |
|
From: silvioprog <sil...@gm...> - 2015-11-21 04:37:49
|
Sorry for the very late answer! ^^' Thanks for the tips, I'm going to use it in a new doc that I'm writing. On Sat, Aug 8, 2015 at 9:46 PM, Michalis Kamburelis < mic...@gm...> wrote: > silvioprog wrote: > > You can use "@file 'your-doc.file.txt'" or "@file", this last option > > will search the file containing the class and method name like > > "TMyClass.MyMethod.txt" in current directory or specified via @dir. > > > > Is it an good idea or I'm daydreaming? =/ > > > > (Sorry for such delay in answering! Busy times....) > > Basically, I see that most of your use-cases are covered by the @include > tag, that allows to include a description from a specified file. See > http://pasdoc.sipsolutions.net/IncludeTag . This basically does what > your @file option would do. > > And to avoid having to write @include... tag too often, you can use > --description command-line option, see > http://pasdoc.sipsolutions.net/ReadDescriptionFromFile . This allows to > place (multiple) descriptions in an external file, and they will be > automatically used by PasDoc. > > So, some of needs are already implemented:) > > What is missing is the automatic guessing of filename to include. That > is, in your proposal, one can write @file without a parameter, and then > the name of the file is automatically guessed from the identified name. > I think that this can be implemented as just an extension of @include > tag? When the parameters are empty, then guess the file name. The > contributions are most welcome:) > > In your proposal, you also add command-line options and tags to specify > the directory where to look for files. These seem like good ideas to > organize descriptions, I only have small notes: > > 1. --doc-source-path= should rather be --include-doc-dir= or such? Just > keep "include" in the name, to make it clear it's used with @include. > > 2. For similar reasons, @dir tag should be called @includeDocDir . Keep > the phrase "include" inside. > > 3. The effect of @includeDocDir should only apply to the current unit. > Otherwise parsing order, command-line order, cache may all cause problems. > > Best regards! > Michalis > > > ------------------------------------------------------------------------------ > _______________________________________________ > Pasdoc-main mailing list > Pas...@li... > https://lists.sourceforge.net/lists/listinfo/pasdoc-main > -- Silvio Clécio |