Phly, boy, phly
the weblog and site of Matthew Weier O'Phinney

In the last two entries in this series on models, I covered using forms as input filters and integrating ACLs into models. In this entry, I tackle some potential infrastructure for your models.

The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). I personally have never been much of a fan of ORMs as they tie models to the underlying database structure; I don't always use a database, nor do I want to rely on an ORM solution too heavily on the off-chance that I later need to refactor to use services or another type of persistence store. On the other hand, the model as a single class is typically too simplistic.

I've fielded several questions about setting up an autocompleter with Zend Framework and Dojo, and decided it was time to create a HOWTO on the subject, particularly as there are some nuances you need to pay attention to.

Just about every day, I have an idea for a blog post, and most days, by the end of the day, I just don't have the time or energy to actually write anything up. The inner writer in me screams, "no excuses!" while the aging adult in me whispers, "time for bed, dear."

So, to keep my hand in the game, here are a few things running through my head, or that I'm working on, or that I'll be doing soon.

I'm a bit late on my ZendCon'08 wrapup; the conference left me both exhausted and with a backlog of email and work that has consumed me since it ended. However, this, too, is good, as it has given me time to reflect... and to finally get my slides up on SlideShare.

ZendCon was alternately exhausting, rewarding, educational, fruitful, infurating, and ultimately wonderful. I've been to every single ZendCon so far -- I started at Zend a scant month before the inaugural event -- and have spoken at each. My first time speaking was a fluke; David Sklar had just started at Ning and had to back out of his "Configuring PHP" tutorial session. Mike Naberezny and I were drafted to take it over, and we had N+1 attendees, where N was the number of speakers. Since that inauspicious beginning, I've gradually taken on more sessions and stuck around to participate in the conference more. I can honestly say that this was the biggest, busiest, and most community focussed ZendCon I can remember.

I've been playing around with Git in the past couple months, and have been really enjoying it. Paired with subversion, I get the best of all worlds -- distributed source control when I want it (working on new features or trying out performance tuning), and non-distributed source control for my public commits.

Github suggests that when working with remote repositories, you turn on the autocrlf option, which ensures that changes in line endings do not get accounted for when pushing to and pulling from the remote repo. However, when working with git-svn, this actually causes issues. After turning this option on, I started getting the error "Delta source ended unexpectedly" from git-svn. After a bunch of aimless tinkering, I finally asked myself the questions, "When did this start happening?" and, "Have I changed anything with Git lately?" Once I'd backed out the config change, all started working again.

In summary: don't use "git config --global core.autocrlf true" when using git-svn.

Now that Zend_Test has shipped, developers are of course asking, "How do I setup my test suite?" Fortunately, after some discussion with my colleagues and a little experimenting on my one, I can answer that now.

Since I originally started hacking on the Zend Framework MVC in the fall of 2006, I've been touting the fact that you can test ZF MVC projects by utilizing the Request and Response objects; indeed, this is what I actually did to test the Front Controller and Dispatcher. However, until recently, there was never an easy way to do so in your userland projects; the default request and response objects make it difficult to easily and quickly setup tests, and the methods introduced into the front controller to make it testable are largely undocumented.

So, one of my ongoing projects the past few months has been to create an infrastructure for functional testing of ZF projects using PHPUnit. This past weekend, I made the final commits that make this functionality feature complete.

The new functionality provides several facets:

• Stub test case classes for the HTTP versions of our Request and Response objects, containing methods for setting up the request environment (including setting GET, POST, and COOKIE parameters, HTTP request headers, etc).
• Zend_Dom_Query, a class for using CSS selectors (and XPath) to query (X)HTML and XML documents.
• PHPUnit constraints that consume Zend_Dom_Query and the Response object to make their comparisons.
• A specialized PHPUnit test case that contains functionality for bootstrapping an MVC application, dispatching requests, and a variety of assertions that utilize the above constraints and objects.

With PHP 5.3 coming up on the horizon, I'm of course looking forward to using namespaces. Let's be honest, who wants to write the following line?

when the more succinct:

could be used? (Assuming you've executed 'use Zend::Controller::Action;' somewhere earlier...)

However, while namespaces will hopefully lead to more readable code, particularly code in libraries and frameworks, PHP developers will finally need to start thinking about sane standards for abstract classes and interfaces.

I've known for some time, but was reluctant to blog about it until the plane tickets were purchased and in hand: I've been invited to speak at the Dutch PHP Conference this coming June:

I'll be presenting two separate sessions: an all day tutorial on 13 June 2008 covering Zend Framework, and a regular session on 14 June 2008 covering Best Practices for PHP development, which will focus on how to utilize Zend Framework coding standards and methodologies to help deliver efficient, high quality code for your organization.

I'm looking forward to meeting old and new friends alike at the conference!

I use Vim for all my editing needs -- TODO lists, email, presentation outlines, coding in any language... everything. So, I thought I'd start sharing some of my vim habits and tools with others, particularly those that pertain to using Vim with PHP.