I've been wanting to play with
HTML_QuickForm for quite some
time, but the documentation has looked rather sparse and scary regarding the use
HTML_QuickForm with Smarty. Since I've been busy
at work, and I haven't wanted to take the time to learn a new library, I've
simply been putting it off.
Last night, I browsed through the package documentation, and noticed a link to an HTML_QuickForm Getting Started Guide by Keith Edmunds. I was pleased to discover that he also has a guide to using Smarty with HTML_QuickForm. I got started with these tutorials, and found them excellent. I found myself wanting a little more meat afterwards, and found that I could now turn to the PEAR docs and actually make sense of it all.
While I think Mr. Edmunds tutorials are great for starters, I found that there were a few pointers I could have used right off the bat. I present them here for you.
I've made two releases of Cgiapp this week, 1.6.2 and 1.6.3.
1.6.2 was tested in a PHP 4.3.4 environment, and features several bugfixes that
give PHP4 compatibility. 1.6.3 fixes a change in
load_tmpl() that broke
As usual, Cgiapp is available on the SourceForge website, as is a complete Changelog and documentation.
I've been working on the Cgiapp roadmap, and particularly on the plugin architecture. I'd been operating under the assumption that I'd have to make a PHP5-specific release (Cgiapp2) to allow this feature. However, it turns out I'm wrong.
A user noted in a comment to my blog on the 1.6.0 release that I'd included a
public keyword in the
s_param() method declaration… which caused
compilation to fail in PHP4. So, quick on the heels of that release, I've
released 1.6.1 to correct this issue. Downloads are available at the
I can't believe I haven't announced this to the world yet, but Jen and I are expecting another baby! The due date is mid-September. And… we decided at the ultrasound this past week we would go ahead and find out the gender… and….
Cgiapp 1.6.0, "Wart Removal", has been released!
This release does not add any new methods, but adds quite a lot in terms of functionality:
s_delete()now works properly.
s_param()now behave gracefully when given bad data (as do a number of other methods)
header_*()suite now function as documented.
croak()no longer echo directly to the output stream (and, in the case of
croak(), die); they use
trigger_error(). This will allow developers to use
croak()as part of their regular arsenal of PHP errors — including allowing PHP error handling. Additionally, most
croak()calls in the class were changed to
carp()as they were not truly fatal errors.
pear install Cgiapp-1.6.0.tgzto get Cgiapp installed sitewide on your system!
As usual, Cgiapp is available at the Cgiapp website.
As promised in my earlier entry from today, here's my quick-and-dirty tutorial on unit testing in PHP using phpt.
First off, phpt test files, from what I can see, were created as part of the PHP-QA effort. While I cannot find a link within the PHP-QA site, they have a page detailing phpt test files, and this page shows all the sections of a phpt test file, though they do not necessarily show examples of each.
Finally, before I jump in, I want to note: I am not an expert on unit testing. However, the idea behind unit tests is straightforward: keep your code simple and modular, and test each little bit (or module) for all types of input and output. If the code you're testing is a function or class method, test all permutations of arguments that could be passed to it, and all possible return values.
Okay, let's jump in!
I've been tinkering with Unit Testing for around a year now, and have tried using PHP Unit as well as Simple Test. It was while following the Simple Test tutorial that I finally grokked the idea of unit testing, and so that has been my favored class for testing.
However, I find writing the tests tedious. In Simple Test, as in PHP Unit, you need to create a class that sets up the testing harness, and then you create a method for each test you wish to run, and so on… I found it incredibly time consuming. Additionally, I found the test harness often felt like a foreign way of testing my code; I was setting up a structure I would never use my code in, typically. All in all, I only test when I have extra time (which is rare) or when I'm really having trouble nailing down bugs (and the unit tests often don't help me find them).
Recently, I've been hearing some buzz over on the PEAR lists and the blogs of some of its developers about 'phpt' tests. From what I hear, phpt tests sound very similar to how one tests in perl (though I've never written perl tests, I've at least glanced through them). However, until recently, I haven't seen any documentation on them, and installing PEAR packages via pear doesn't install tests.
We got a copy of PHP5 Power Programming a few weeks ago, and in the section on preparing a PEAR package was a brief section on phpt tests. The section was small, and when I looked at it, my immediate thought was, "it can't be that simple, can it?"
So, I decided to try it out with Cgiapp. A few minutes later, I had some working tests for my static methods. "Hmmm," I thought, "That was easy. Let's try some more."
Turns out they're kind of addictive to geeks like me. In a matter of a few hours, I'd knocked out tests for over half the functionality, and disccovered, to my chagrine and joy, a number of bugs and bad coding practices… which I promptly corrected so I could get that magical 'PASS' from the test harness.
In the process of writing the tests, my understanding of the tool evolved quite a bit, and by the end, I had the knack for it down. I'll blog later about some of the ways I made them easier to use for myself — and how I made them more useful for debugging purposes.
I just had to add a note over on PHP.net regarding abstract classes and methods: Object Abstraction.
I'm working on Cgiapp2, which is a PHP5-only implementation of Cgiapp that is built to utilize PHP5's new object model as well as exceptions. One thing I decided to do, initially, was to make it an abstract class, and to mark the overridable methods as abstract as well.
In testing, I started getting some strange errors. Basically, it was saying in my class extension that an abstract method existed, and thus the class should be marked as abstract, and, finally, that this means it wouldn't run.
What was so odd is that the method didn't exist in the extension at all.
So, I overrode the method in the extension… and voila! Everything worked fine.
The lesson to take away from this is quite simple: if the method does not need to be present in the overriding class, don't mark it as abstract. Only mark a method as abstract if:
Now I need to update my source tree…. :-(
Greg Beaver writes in his blog about PEAR, the new PEAR channels, and some issues he sees with PEAR and its developers. Greg is responsible for the latest version of PEAR and the PEAR installer — and for the development of PEAR channels. The particular link referenced above makes reference to a thread on the PEAR-dev mailing list… that I originated, when asking whether or not Cgiapp might be a good fit for PEAR.