Wednesday, July 30. 2003

For years we have used Dave Raggett'sTidy utility to fix an incredible number of problems and accessibility issues associated with the creation of HTML and XHTML documents. Today I'm announcing the 0.5beta release of a PHP extension based on Libtidy which provides all the functionality of Tidy in ways that just couldn't be done from the command line!

Not only does the Tidy Extension provide all of the normal functionality you'd expect from an implementation of tidy from within PHP, but it also provides a complete API for traversing and pulling data out of the parsed HTML tree using the Zend Engine 2 object-oriented constructs. (see the examples/ directory for example scripts)


You can find the Tidy extension, documentation, tests and examples at the following URL (soon to be replaced with a more appropiate long-term home):http://www.coggeshall.org/php/php-tidy-0-5b.tar.gz

Wednesday, July 30. 2003

For years we have used Dave Raggett'sTidy utility to fix an incredible number of problems and accessibility issues associated with the creation of HTML and XHTML documents. Today I'm announcing the 0.5beta release of a PHP extension based on Libtidy which provides all the functionality of Tidy in ways that just couldn't be done from the command line!

Not only does the Tidy Extension provide all of the normal functionality you'd expect from an implementation of tidy from within PHP, but it also provides a complete API for traversing and pulling data out of the parsed HTML tree using the Zend Engine 2 object-oriented constructs. (see the examples/ directory for example scripts)


You can find the Tidy extension, documentation, tests and examples at the following URL (soon to be replaced with a more appropiate long-term home):http://www.coggeshall.org/php/php-tidy-0-5b.tar.gz

Saturday, July 26. 2003

As I did the other day, I've dug into the vault-o-John again today and put online a new column. Today's column is entitled "PHP References" and is a comprensive look at the topic of references in PHP. If you ever were unclear as to exactly how references work, this should do a lot to answer your questions!

• References in PHP

Saturday, July 26. 2003

As I did the other day, I've dug into the vault-o-John again today and put online a new column. Today's column is entitled "PHP References" and is a comprensive look at the topic of references in PHP. If you ever were unclear as to exactly how references work, this should do a lot to answer your questions!

• References in PHP

Friday, July 25. 2003

Here's a little piece of wisdom to those who write columns online such as myself who also run a web site, have a book to promote, etc.

When writing columns for a company such as I do with my column @ onlamp.com, often they will force you to sign over all rights to the work. Generally, I have been okay with this however I have always made sure there is a clause in my contract stating that my work will always be credited to me, regardless of who actually owns it.

Well, that's great but I realized today that I really should have asked for two things -- credit and a link. You see, for about a year and a half I was the columnist for Zend.com's Code Gallery Spotlight. During my time with Zend, I wrote a huge number of articles that are quite popular even today (you can find the ones I wrote in the Publications section).

After I stopped writing for Zend, they of course found a new columnist and the column has gone on. The problem is that even though all of the columns which I wrote I am getting credit for in the by-line, since there is no link my work is getting thrown under this new columnist's belt -- at least when it comes to attracting hits to our respective web sites.

So, here's the advice for the day: Get credit, and get a link to your site on EVERY column you publish. If your really smooth, require a bio at the bottom of every column as well. You'll thank me for it later.

Friday, July 25. 2003

Here's a little piece of wisdom to those who write columns online such as myself who also run a web site, have a book to promote, etc.

When writing columns for a company such as I do with my column @ onlamp.com, often they will force you to sign over all rights to the work. Generally, I have been okay with this however I have always made sure there is a clause in my contract stating that my work will always be credited to me, regardless of who actually owns it.

Well, that's great but I realized today that I really should have asked for two things -- credit and a link. You see, for about a year and a half I was the columnist for Zend.com's Code Gallery Spotlight. During my time with Zend, I wrote a huge number of articles that are quite popular even today (you can find the ones I wrote in the Publications section).

After I stopped writing for Zend, they of course found a new columnist and the column has gone on. The problem is that even though all of the columns which I wrote I am getting credit for in the by-line, since there is no link my work is getting thrown under this new columnist's belt -- at least when it comes to attracting hits to our respective web sites.

So, here's the advice for the day: Get credit, and get a link to your site on EVERY column you publish. If your really smooth, require a bio at the bottom of every column as well. You'll thank me for it later.

Tuesday, July 22. 2003

A number of months ago I was asked if I'd be interested in writing for the first printed PHP magazine PHPJ. Specifically, I wrote an article on sending file attachments from within PHP scripts using MIME and one on templating for what was to be my "Best Practices" column.

For reasons that aren't entirely clear, the magazine never materialized and these columns have been gathering dust ever since. Since they might be useful to someone I've decided to make them available to everyone.

Disclaimer: These columns are rough drafts :) If you find typos feel free to let me know.

Here's a few links:

• Sending File attachments in mail from PHP
• Separating business and presentation

Update: With the new site design, these columns are not currently available online. I'll do my best to get them online soon.

Tuesday, July 22. 2003

A number of months ago I was asked if I'd be interested in writing for the first printed PHP magazine PHPJ. Specifically, I wrote an article on sending file attachments from within PHP scripts using MIME and one on templating for what was to be my "Best Practices" column.

For reasons that aren't entirely clear, the magazine never materialized and these columns have been gathering dust ever since. Since they might be useful to someone I've decided to make them available to everyone.

Disclaimer: These columns are rough drafts :) If you find typos feel free to let me know.

Here's a few links:

• Sending File attachments in mail from PHP
• Separating business and presentation

Update: With the new site design, these columns are not currently available online. I'll do my best to get them online soon.

Monday, July 21. 2003

Once upon a time last year, I stood up in the PHP internals community to support the idea of a re-thinking of the way PHP handles errors. Although I wasn't as informed regarding the internals of PHP back then, as time has gone on and I have spent more and more time tinkering with it I have come to the conclusion that error handling in PHP is just as bad as I argued it was.

There are a great number of people in the internal PHP community which feel that the error handling system is just fine -- either that or they don't care very much to worry about it. Regardless, the fact of the matter is that error handling in PHP has basically not changed what-so-ever since PHP3... considering PHP 3.0.18 was released sometime in October 2000, well.. you do the math.

Recently, (sparked by Marco'svar_dump_html() patch) I have began to investigate the way PHP handles errors again. Again, I have come to the conclusion that there is absolutely no way to improve the current error system without completely re-thinking the way PHP (and for that matter, the Zend engine itself) handles errors. Here's the problems I see with the current way PHP deals with errors.

1. It's not user friendly
   Errors in PHP are, in the best light, not very useful. In general they are very brief, generalized, and there is no correlation between an error message and the PHP documentation. Although efforts have been made to make this "better" by automatically adding links to the error message to a PHP manual reference, it was a complete disaster and really ended up contributing nothing useful.
2. Messages are hard-coded
   From a programmerÂ’s standpoint, I am of the firm belief that programs should be as flexible as possible within reason. However, for some reason (which I attribute to legacy PHP3 code) all error messages within PHP are hard-coded strings scattered throughout the source tree.

3. Not machine understandable
   Although this is in the same line, hard-coded strings without some sort of unique error-code cannot be understood in any sort of reasonable fashion by PHP itself. This inability to pinpoint the exact error which has occurred by the language itself is a major flaw in my opinion, as it not only makes things such as internationalization impossible but also prevents others from writing more robust error handling extensions for PHP.

4. Improper classification of non-fatal errors
   As we all know, there are a number of different classifications of errors such as E_ERROR which are used to identify the significance of the error which has occurred during the execution of a PHP script. It is accepted that E_ERROR errors are designed to be script-halting fatal errors, E_WARNING errors are non-halting errors and E_NOTICE are simply that -- notices. Unfortunately, these conventions have not always been followed and A number of errors which are non-fatal have been classified as E_ERROR, leading to a further unnecessary complexity in the error handling system.

5. Improper use of error handling API
   Although this is more an issue of the philosophy used in the design of PHP than a flaw, in my opinion the error handling API is improperly used in many cases. Specifically I am referring to the use of the same error mechanisms throughout the source tree. By failing to logically distinguish between errors which occur in the SAPI modules to those which occur within an extension (or internally within the engine) yet another limiting factor to the error handling model is introduced.

Based on the reasons I have outlined above, I feel that serious efforts be made to re-think the way PHP handles errors in the future. A number of proposals have been made and I have personally spoken to a number of the internals developers regarding this issue, and unfortunately I must say the greatest limiting factor seems to be based more in politics than in a lack of solutions – the greatest of these arguments being a resistance to breaking backward compatibility with previous versions of PHP.

Although I understand the need to maintain backward compatibility with older PHP scripts, but I find the argument loses most of its weight considering the up-coming PHP5 release which already breaks backward compatibility with PHP4 in a number of ways. I must wonder, if backward compatibility will be broken for the benefit of the language in some respects why not take the opportunity to break it in other equally beneficial ways?

Looking at the current situation of error handling in PHP, it seems to me the most reasonable solution which addresses the problems I have identified is to move all error handling into the exception model (new to  PHP5). Currently, although exceptions can be thrown and caught in PHP scripts, the PHP engine itself will still use the old-style error handling  instead of the new model. By wrapping all errors into exceptions a number of possibilities for future improvement of the error handling system can be introduced. I concede that such a change cannot be done without breaking that grail of backward compatibility on some level, but in this case I feel that those compatibility issues can be justified. 

In the proposed exception-based error handling system, all internal PHP errors which were non-fatal would cause an exception to be thrown. This exception, if not caught by the executing script would be caught by the internally and the standard error message would be generated. This causes the most significant problem in self-contained libraries which may be taking advantage of the current error-handling system as part of their library’s logic (which, coincidently, is exactly the “if we put it in the language, it will be abused� argument seems to be all about). In the proposed error system, the logic of these libraries could be broken if they are used in conjunction with the try/catch paradigm. For example, if a library causes an error an exception would be thrown. However, since that exception is caught by a try/catch block outside of the library the PHP4-style error message will never be generated and thus the custom error handler within the library never called.

Examining this situation, I claim that this problem is not a sufficient enough reason to abandon the idea of an exception-based error model for PHP. Rather, it simply must be something that is considered in the design of the model. For instance, one immediate solution to this dilemma which comes to mind is to restrict the use of the new exception-based error model to situations where a custom user-space error handler is not being used and maintaining the error-suppression operator @Â’s meaning in the new model. If no custom error handling mechanism is in place, then it can be assured that there is no underlying logic within a library which will be affected by the exception-based model. Thus, huge improvements can be made to the error handling system in PHP without causing hard to diagnose and explain bugs in legacy PHP4 code.

Understandably, I am accepting of the criticism that everything I have written in this mini-essay is great – but it means nothing unless it is implemented. To that I answer that I would gladly volunteer the spare time I have to designing and implementing such an improved error handling system for PHP5 or any other future version, however since this implementation is such a massive change to a fundamental part of the language I cannot do so without support from the internals community. Although I have written an extensive amount on the subject of PHP errors in this post I haven't done more than point out other deeper underlying issues such as the lack of a proper separation between errors in the different sections within PHP. I have avoided this issue because I believe a solid exception-based error handling model within PHP will provide the tools needed to solve these secondary issues without significant difficulty.

In the end, IÂ’m writing this to bring the issue up, share my ideas and offer my time if the idea is accepted. Comments of any sort of very welcome.

Monday, July 21. 2003

Once upon a time last year, I stood up in the PHP internals community to support the idea of a re-thinking of the way PHP handles errors. Although I wasn't as informed regarding the internals of PHP back then, as time has gone on and I have spent more and more time tinkering with it I have come to the conclusion that error handling in PHP is just as bad as I argued it was.

There are a great number of people in the internal PHP community which feel that the error handling system is just fine -- either that or they don't care very much to worry about it. Regardless, the fact of the matter is that error handling in PHP has basically not changed what-so-ever since PHP3... considering PHP 3.0.18 was released sometime in October 2000, well.. you do the math.

Recently, (sparked by Marco'svar_dump_html() patch) I have began to investigate the way PHP handles errors again. Again, I have come to the conclusion that there is absolutely no way to improve the current error system without completely re-thinking the way PHP (and for that matter, the Zend engine itself) handles errors. Here's the problems I see with the current way PHP deals with errors.

1. It's not user friendly
   Errors in PHP are, in the best light, not very useful. In general they are very brief, generalized, and there is no correlation between an error message and the PHP documentation. Although efforts have been made to make this "better" by automatically adding links to the error message to a PHP manual reference, it was a complete disaster and really ended up contributing nothing useful.
2. Messages are hard-coded
   From a programmerÂ’s standpoint, I am of the firm belief that programs should be as flexible as possible within reason. However, for some reason (which I attribute to legacy PHP3 code) all error messages within PHP are hard-coded strings scattered throughout the source tree.

3. Not machine understandable
   Although this is in the same line, hard-coded strings without some sort of unique error-code cannot be understood in any sort of reasonable fashion by PHP itself. This inability to pinpoint the exact error which has occurred by the language itself is a major flaw in my opinion, as it not only makes things such as internationalization impossible but also prevents others from writing more robust error handling extensions for PHP.

4. Improper classification of non-fatal errors
   As we all know, there are a number of different classifications of errors such as E_ERROR which are used to identify the significance of the error which has occurred during the execution of a PHP script. It is accepted that E_ERROR errors are designed to be script-halting fatal errors, E_WARNING errors are non-halting errors and E_NOTICE are simply that -- notices. Unfortunately, these conventions have not always been followed and A number of errors which are non-fatal have been classified as E_ERROR, leading to a further unnecessary complexity in the error handling system.

5. Improper use of error handling API
   Although this is more an issue of the philosophy used in the design of PHP than a flaw, in my opinion the error handling API is improperly used in many cases. Specifically I am referring to the use of the same error mechanisms throughout the source tree. By failing to logically distinguish between errors which occur in the SAPI modules to those which occur within an extension (or internally within the engine) yet another limiting factor to the error handling model is introduced.

Based on the reasons I have outlined above, I feel that serious efforts be made to re-think the way PHP handles errors in the future. A number of proposals have been made and I have personally spoken to a number of the internals developers regarding this issue, and unfortunately I must say the greatest limiting factor seems to be based more in politics than in a lack of solutions – the greatest of these arguments being a resistance to breaking backward compatibility with previous versions of PHP.

Although I understand the need to maintain backward compatibility with older PHP scripts, but I find the argument loses most of its weight considering the up-coming PHP5 release which already breaks backward compatibility with PHP4 in a number of ways. I must wonder, if backward compatibility will be broken for the benefit of the language in some respects why not take the opportunity to break it in other equally beneficial ways?

Looking at the current situation of error handling in PHP, it seems to me the most reasonable solution which addresses the problems I have identified is to move all error handling into the exception model (new to  PHP5). Currently, although exceptions can be thrown and caught in PHP scripts, the PHP engine itself will still use the old-style error handling  instead of the new model. By wrapping all errors into exceptions a number of possibilities for future improvement of the error handling system can be introduced. I concede that such a change cannot be done without breaking that grail of backward compatibility on some level, but in this case I feel that those compatibility issues can be justified. 

In the proposed exception-based error handling system, all internal PHP errors which were non-fatal would cause an exception to be thrown. This exception, if not caught by the executing script would be caught by the internally and the standard error message would be generated. This causes the most significant problem in self-contained libraries which may be taking advantage of the current error-handling system as part of their library’s logic (which, coincidently, is exactly the “if we put it in the language, it will be abused� argument seems to be all about). In the proposed error system, the logic of these libraries could be broken if they are used in conjunction with the try/catch paradigm. For example, if a library causes an error an exception would be thrown. However, since that exception is caught by a try/catch block outside of the library the PHP4-style error message will never be generated and thus the custom error handler within the library never called.

Examining this situation, I claim that this problem is not a sufficient enough reason to abandon the idea of an exception-based error model for PHP. Rather, it simply must be something that is considered in the design of the model. For instance, one immediate solution to this dilemma which comes to mind is to restrict the use of the new exception-based error model to situations where a custom user-space error handler is not being used and maintaining the error-suppression operator @Â’s meaning in the new model. If no custom error handling mechanism is in place, then it can be assured that there is no underlying logic within a library which will be affected by the exception-based model. Thus, huge improvements can be made to the error handling system in PHP without causing hard to diagnose and explain bugs in legacy PHP4 code.

Understandably, I am accepting of the criticism that everything I have written in this mini-essay is great – but it means nothing unless it is implemented. To that I answer that I would gladly volunteer the spare time I have to designing and implementing such an improved error handling system for PHP5 or any other future version, however since this implementation is such a massive change to a fundamental part of the language I cannot do so without support from the internals community. Although I have written an extensive amount on the subject of PHP errors in this post I haven't done more than point out other deeper underlying issues such as the lack of a proper separation between errors in the different sections within PHP. I have avoided this issue because I believe a solid exception-based error handling model within PHP will provide the tools needed to solve these secondary issues without significant difficulty.

In the end, IÂ’m writing this to bring the issue up, share my ideas and offer my time if the idea is accepted. Comments of any sort of very welcome.

Friday, July 18. 2003

"Sure, I'm f&@!ing drunk! But I'm fricken creditable!"

:) Those who were there will know what I'm talking about :)

Friday, July 18. 2003

"Sure, I'm f&@!ing drunk! But I'm fricken creditable!"

:) Those who were there will know what I'm talking about :)

Monday, July 14. 2003

Although I don't get much chance to read, every time I do get a chance I've always been impressed with PHP|architect. It's always been an informative source of information on PHP which, for a reasonable price IMO, has been electronically distributed in PDF format. Well, that's always been kind of a problem for me -- after all, laptops die, plane rides are long, and i haven't turned on that damn PDA I baught in years. However, according to the PHP|A Blog they'll soon have a print edition also available. Very cool.

Monday, July 14. 2003

Although I don't get much chance to read, every time I do get a chance I've always been impressed with PHP|architect. It's always been an informative source of information on PHP which, for a reasonable price IMO, has been electronically distributed in PDF format. Well, that's always been kind of a problem for me -- after all, laptops die, plane rides are long, and i haven't turned on that damn PDA I baught in years. However, according to the PHP|A Blog they'll soon have a print edition also available. Very cool.

Monday, July 14. 2003

I didn't want to announce this until I was sure the change was final, it appears that now is a good time to announce that the name of my book has changed from "PHP Unleashed" to "PHP Developer's Handbook". This change really is fairly cosmetic, however this change does make the book slightly smaller and more focused.

New look, same great content!