> * Conventions for what sections should be in the POD's and how they > should be formatted so that a parser can pick up the data. > The POD style doc is here: > > http://www.officevision.com/pub/p5ee/software/htdocs/P5EEx/Blue/podstyle.htm l
There are a lot of good thought in it, but I would prefer to not put pod directly into the module but create it out of the special comments, for reasons I have outlined in my other mail. > > * A javadoc-style frame generator which > 1. creates the frames docs, summary docs, and xref docs we are familiar > with from javadoc. See some preliminary output can be seen here: > http://www.officevision.com/pub/p5ee/software/htdocs/api/ > 2. will validate as many of the redundant pieces of information as possible > which are coded into the POD doc with each other and with pieces of > information which can be parsed from the Perl code itself. > This will be highly configurable as to what generates a warning, what > generates an error, etc. so that a project can be very strict or not > so strict. I agree > The generator/validator I have whipped together are called "perldocs" > ("perldoc" was already taken). ;-) "perldoc" is in the P5EEx::Blue > area, under the "sbin" directory, and it fits well into the Makefile.PL > process. See it at: > I think we need some more "advanced" here, that is splitted accross mutiple objects and allows to plug in different output formatter etc. For the output generation side, Stas DocSet is a good point to start, for the parser I like to take a look at what James Tillman has done. > > I guess it makes sense for those who are serious about working on the > documentation and meta-data-for-bean-like-behavior stuff to declare themselves > so that we don't hopelessly duplicate our efforts. Nonetheless, like the > rest of P5EEx, there will be plenty of duplication while things are > prototyped. > I really like to get agreement before I start coding. My time as very limited (I guess this is the same for most or all on the list) and I don't like to waste to much time implementing something to throw it away afterwards. (Of course you always have to throw away parts and redo them) Gerald ------------------------------------------------------------- Gerald Richter ecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131 WWW: http://www.ecos.de Fax: +49 6133 925152 -------------------------------------------------------------
