There and Back Again

Greg and I released phpDocumentor 1.3.0 RC2 today, getting really close to a 1.3.0 release, though if the daily changes on php5 features don’t stop it will take at llast 1 more release to support ph5p finale:

Release Announcement follows:

The phpDocumentor team is pleased to announce the release of phpDocumentor 1.3.0 RC2.

This release add PHP 5 support and a number of bug fixes

This will be the last release in the 1.x series. 2.0 is next.

Features added to this release include:

• Full PHP 5 support, phpDocumentor both runs in and parses Zend Engine 2
  language constructs. Note that you must be running phpDocumentor in
  PHP 5 in order to parse PHP 5 code
• inline {@example} tag – this works just like {@source} except that
  it displays the contents of another file. In tutorials, it works
  like <programlisting>
• customizable README/INSTALL/CHANGELOG files
• phpDocumentor tries to run .ini files out of the current directory
  first, to allow you to put them anywhere you want to
• multi-national characters are now allowed in package/subpackage names

Notice: PEAR users will want to read the release notes for directions on how to automatically setup the web interface on install

Documentation http://phpdoc.org/docs/
Release Notes http://phpdoc.org/notes/Release-1.3.0

ChangeLog http://phpdoc.org/notes/ChangeLog
Download http://phpdocu.sourceforge.net/downloads.php

I’m pleased to announce that Nusphere PhpED 3.3 is shipping with a bundled version of phpDocumentor.

The integration is nicely done, and makes it extremely easy to generate docs for projects you have setup in PhpED.

For more details checkout:

http://www.nusphere.com/

http://www.nusphere.com/products/index.htm

also if someone wants to writeup a little page showing the integration and howto use it let me know, its not hard to use but I would like to promote this hoping that phpDocumentor will get integrated in some of the other PHP IDEs as well.

The new release of Nusphere PhpED includes an intergrated bundled copy of phpDocumentor. I’ll get some screen shots and a quick howto up once I get the eval version installed, and phpDocumentor 1.3.0rc1 out on the SF servers.

Got an interesting email a couple days ago. Seems on of the commercial PHP IDE’s will be shipping phpDocumentor with its next release.

Its nice to get to a point where someone would considering doing this instead of doing their own thing like Zend has done.

I’ll do a full announcement with more details when things are actually released, I don’t think its a big secret or anything but I’m making everyone playing the guessing game until I have a feature page with phpDocumentor on it to link too.

I started implementing the new reflection code I mentioned a couple posts ago. I’m trying to stick close to the php5 Reflection class but this design needs to be a little different since it has some different organizational structures and you need to work with large amounts code at one.

After i get this coded up with some test data pushed into it by hand i’ll start working on the new converter that uses this, hopefully i can make some progress over the next week.

Anyhow here is tonights code, I’ll attempt to get it into cvs after the ideas are actually almost usable.

Walking back from the bookstore I had some really good ideas for the converter design in phpDocumentor 2.0

First the parser should ouput a flat tree of objects representing the code, we can use the php5 reflection classes for the design of this, im guessing will have to extend them a bit and add docblock access methods.

My main idea deals with howto manage template complexity it borrows a bit from the discussion surrounding the PEAR delegation class submission and howto allow base templates with overrides on the Savant list.

First the accessors on the objects representing your parsed code should always call an encode method. The default method will just return the data with no changes, but for HTML or XML output the encode method can be delegated to a utility class that takes care of there requirements. There should also be a helper class for each output type that does the standard stuff like create a link or a class tree. If these options can be made exteremly generic then you really only need 2 converters, the rest is templates and setup of the helper and delegated classes.

The 2 converter are of course a single file output converter and a multi-file output converter. Hmm maybe only one coverter with options for where to break out pages, Project,Package,Class,Page, etc. Then you just need to hand the class the template file match-up for the fileoutputs selected.

Also i think its a good idea to make the template engine a selectable option, and that when any engine that implements the same interface as Savant can be used.

Finally one of the biggest parts of converter complexity can be manage by using template inheiritance. The default style goes into a directory called shared. Then the template selected goes into another directory. The include path is set to first the selected templates dir and then the shared dir. That way to make a new template you only have to create new files for what you want to change.

This same approach can also be used for css files, only in this case we just use the cascading feature of css, you always include the base css files and then just add new ones for the specific template the override the base one.

The only big issue i see is the Frames no frames output, but i think that can be managed since you always have that nav code its just what file it goes into, would should be able to push that to a template choice with a little bit of thought.

Comments and code are of course always welcome.