Re: [REMINDER] Tools and Utilities::PDS

Greg Beaver wrote:

Hi Davey, I think the idea of having a more useful .phps is good, perhaps a good package name is PHP_Advanced_phps, or some other name that stresses the connection to .phps/highlight_file().

Hmm, not sure about the name... what would the filename end up? PHP/Advanced_phps.php?

I also think your economy of code is good. I do have a few problems with the package as it stands that I would like to see fixed before a release, and some are major, so feel free to veto :) 1) it should use external files for all formatting. These don't have to be templates, but can be PHP files that are included to allow user formatting and customization.

It already allows for a custom CSS stylesheet to be defined, if it is, *no* default CSS will be included (though the names must be consistant with the standard ones to work). This is done using a config file (named pdsconfig.inc.php is this OK? it's include 'pdsconfig.inc.php'; which means it will pick up versions in current directory and include_path, this seems the best nicest way to allow this so multiple users can use the PEAR class with their own config). Oh and I'm also going to see about using the php.ini highlight.* settings by default if they exist though this could just add bloat, checking for them all and falling back to my defaults if not there. Opinions?

2) Since it is a PEAR class, it should have an API to allow extension and customization of child classes. I would rename doHTML() to parseTokens() and have it only organize tokens by type, and apply a separate helper function toHTML(), which is specified as an option (in other words, the future PDS extension might use toXML() instead or even toFlash(), based on a constructor argument $outputFunc = 'toHTML'). In this way, users can extend parseTokens() to specify different groupings of tokens, and apply their own output functions to these groupings

I like the idea, a lot, because there would be no BC break with this (as the user should not be calling PDS directly, and if they do, only the constructor) so I would like to work on this after a alpha/beta release

3) As you say, the documentation should link to source code line. For this purpose, you could use PHP_Parser easily (just parse the source, grab the line number from the returned array, and use it to link, and add in <a name> for each line number)

Great to know this, how are the docs for this coming along? I assume there *must* be at least phpDocumentor docs for it ;)

4) For this purpose, I think the documentation is much too large. I would like to see more of a tabular look (don't have to use <table> for this) as the default look.

Agreed, I will certainly play about with the docs, will see about implementing some sort of system similar to what you mentioned about doHTML(), that way it can be extensible easily :)

5) I'd like an option to hide all private elements, as technically, they should never be called or extended from outside the current class. I wonder if your functions should have @access protected for that reason

Another good idea, perhaps make another config option to make the visible but keep them hidden by default. Although don't forget they will still be in the actual source...

Hope these comments are helpful :) Most of these points won't stop me from +1ing, but I want to see #1 and #2 before I give a +1, so I'll give a +1/2 :). PDS is a great idea and you've done good work. With those changes, I think it will be a really useful tool.

Aww shucks! :)

Greg

- Davey