Re: Re: phpDocumentor tutorials/extended documentation implementation

I think the general consensus when you look deeply at the problem is that making the API docs embedded into the code doesnt really work that well. From the perspective of the phpdocu -> phpman conversion, I would think a base level tool (having tried this already :)... would Condition: (Class/Methods) no phpmanual page exists: --create docbook xml files with information from phpdocu. .. and just splatter the 'description/example' code into a single (or maybe 2) para section. (let the end user sort it out) Condition: (Class/Methods) phpmanual already page exists: just check that the methods return & arguments match??.. (or just check the file exists!) In this case It shouldnt be to complex.. a) to implement, b) to use.. the assumption after you have generated the docbook manual, you should be able to open up the docbook file in staroffice (hopefully).. and just edit away.... The only thing that was evident in having a go at this was that a 'dont generate documents for this file' condition was needed for things like drivers (DB_mysql, or Image_Transform_GD) regards Alan Alexander Merz wrote:

Greg Beaver wrote:

put tutorials in a special directory tutorials/packagename/[subpackagename/]. tutorials is a subdirectory of any directory parsed.

- file role="doc" in package.xml - peardoc (intro-section is exaktly dedicated for this) The problem is not to make tutorials public, the problem is the force programmers to write real docs. Tutorials and an API-Doc are a good excuse for programmers not to write end user docs like peardoc want to be. Tutorials are often superficially, the auto-generated API-Doc contains to much stuff for the end user. You propose for a docbook-styled markup for tutorial was already discussed months ago and gets no real feedback.