Diagnostic Output Class Gets Even Niftier

by Alan Langford | 2008-01-10 | It's a Code, Code World

Shortly after finishing the PHP AP5L_Debug class, I encountered a nasty problem with an AJAX enabled page. Although it’s possible to include diagnostic information in an AJAX response, the client side JavaScript has to figure out it’s there and then figure out how to display it in a sensible way, which also means putting it on the page in some dynamic HTML, or extracting it in a debugger. That’s just not fun.

Or you can try setting up an XDEBUG connection, which seems like a lot of work for a couple of diagnostic messages, and if you’re running on some shared hosting plan, you can probably forget about that anyhow.

So I figured why not just route the diagnostics out through a socket and write the output on a console somewhere?

So after a little work, AP5L_Debug now offers two variations.

• AP5L_Debug_Stdout just echoes the data to the output stream (well not quite: if no headers have been sent, it buffers the data and then writes everything on the first post-header output, or on an explicit flush).
• AP5L_Debug_Udp sends the data to the address and port of your choice. There’s also AP5L_Debug_Listener, which is a crude command line tool that reads data from the port and dumps the information to the console.

It worked like a charm. The diagnostics identified what was a pretty simple mistake, I fixed the code, and the problem was solved in no time.

Also, since the diagnostics don’t mess up the generated page, I can see using this technique even when there’s no AJAX involved. That’s more than welcome.

AP5L Gets a Nifty Diagnostic Output Class

by Alan Langford | 2008-01-08 | It's a Code, Code World

I just added a class to the AP5L PHP library that does something I’ve wanted for a long time.

Most applications have a debug mode that shows developers what’s going on under the hood, so that they can diagnose problems. The problem with these modes is always selectively controlling what gets displayed at runtime. Most of the time, debugging is an on/off switch. Turn it on and you get reams of information. Usually only a small part is relevant and you have to dig through it all to find the information you need.

The AP5L_Debug class maintains an array of debug settings. The format of a setting is “type@namespace::class::method”. Any value can be associated with a setting. The setting mechanism allows simple fine-grained control over what gets written as diagnostics. Want to turn on all the diagnostics in MyClass? Simple. Do it with AP5L_Debug::getInstance() -> setState(‘::MyClass’, true); Only interested in the close function? AP5L_Debug::getInstance() -> setState(‘::MyClass::close’, true);

The real joy of this is that the actual output statements remain very simple. Just use AP5L_Debug::getInstance() -> write(‘My debugging message); Debug automatically figures out the class and method names, and looks for relevant settings. Namespaces will be implemented when they arrive in PHP 5.3.

There’s some more great features as well. Check out the comments at the beginning of the AP5L_Debug class.

Elegant Runtime Configuration

by Alan Langford | 2008-01-08 | It's a Code, Code World

While working on a unit test facility for the “Joomla!” project, one of the developers made me aware of functions in the “Standard PHP Library” that let you do some powerful things with class auto-loading.

One of the biggest challenges with code libraries is making them easy to configure in a wide range of server environments. PEAR is a large, powerful set of packages that is useful in just about any application, but getting the installation right can be a real pain, particularly in shared hosting environments.

The SPL allows an application to manipulate a stack of auto-load functions. So now to use AP5L, all you have to do is include the base AP5L.php file and then call AP5L::install(). The “installer” injects an auto-loader that recognizes all AP5L classes. Since the code for these classes is relative to the base AP5L.php, it can derive the appropriate file name from the class name with ease. If the class isn’t part of AP5L, it simply passes it along to the next loader in the stack.

AP5L::install() also has an option for a more traditional approach, adding the install path to PHP’s include file path. However this leaves the application with the responsibility of including the class files before they’re used. In highly tuned systems with performance optimizers there are some good reasons to load all classes in one shot, and this option makes that slightly easier. [If you’re really interested in performance, the best easy thing to do is to merge everything into one big file, stripped of comments and whitespace, but that’s another topic.]

RapidForm Refactored for AP5L

by Alan Langford | 2008-01-07 | It's a Code, Code World

One day I needed a simple form for list subscription that needed a CAPTCHA image and I didn’t want to go through the trouble of trying to crowbar it into any of the “complex” PEAR form packages.

So I thought “why not build something really simple and lightweight that will create and validate a simple form?” I wanted three methods: create, validate, and save. Sweet, simple, easy to code.

That might not have been the smartest thing I ever did. (more…)