Somebody on Twitter pointed this out, and I thought I'd spread the word: DHH of Rails fame has posted a nice, short, and very interesting thought on "The immediacy of PHP".
I've been delving a little into Rails lately myself, and what I find is: use the right tool for the job. For green-field, self-hosted projects, Rails is not a bad choice, and offers a very easy way to get your application up and running quickly. But due to the fact that PHP was built for the web, there are any number of tasks that are simpler and faster to accomplish using it. Evaluate your needs carefully, and choose the tool that best addresses them.
It's nice to see leaders of projects like Rails having this same attitude. It's a breath of fresh air in the competitive market of web development frameworks.
Cal has released a new PHP Abstract podcast today on the Zend Developer Zone, an interview with Wil Sinclair, the project manager for Zend Framework, and Brad Cottel, Zend's product Evangelist. In it, they talk quite a bit about the work I've done on Zend Form, and also a lot about the proposal process.
If you're interested in the new 1.5 features, or how the proposal process works and who contributes to the community, give it a listen!
Dojo announced today the availability of 1.1.0.
I've been toying with Dojo off-and-on for almost a year now. It's the most framework-y of the various JS toolkits I've tried, and I particularly appreciate its modularity. (That said, it can lead to a lot of HTTP requests to your site if you don't create a targetted bundle with the modules you need.)
The 1.1.0 release has me pretty excited, as it finally is doing something most
other JS frameworks have been doing for some time: its XHR requests now send
the X-Requested-With: XMLHttpRequest
header, which allows it to conform to
the isXmlHttpRequest()
method in Zend Framework's request object. This makes
it much easier to provide a standard mechanism in your server-side code for
detecting AJAX requests, allowing context switching to be automated.
Update: this article is now available in French, courtesy of Frédéric Blanc.
I've fielded a number of questions from people wanting to know how to handle authentication and identity persistence in Zend Framework. The typical issue is that they're unsure how to combine:
It's not terribly difficult, but it does require knowing how the various pieces
of the MVC fit together, and how to use Zend_Auth
. Let's take a look.
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.
Somebody asked for some examples of how I use the headLink()
, headScript()
,
and other placeholder helpers, so I thought I'd take a crack at that today.
First off, let's look at what these helpers do. Each are concrete instances of a placeholder. In Zend Framework, placeholders are used for a number of purposes:
Let's look at these in detail.
As many know, Zend Framework 1.5.0 is almost ready for release… heck, it might even be released by the time you read this. There are a ton of new features worth looking into, but I'll list some of my own favorites here - the ones I've been either working on or using.
Full disclosure: I am employed by Zend to program Zend Framework. That said, the following is all my opinion, and is based on my experiences with Zend Framework, as well as answering questions on a variety of mailing lists and with other OSS projects (PEAR, Solar, and Cgiapp in particular).
One of my biggest pet peeves in the OSS world is vague bug/issue reports and feature requests. I cannot count the number of times I've seen a report similar to the following:
<Feature X>
doesn't work; you need to fix it now!
If such a report comes in on an issue tracker, it's invariably marked critical and high priority.
What bothers me about it? Simply this: it gives those responsible for maintaining Feature X absolutely no information to work on: what result they received, what was expected, or how exactly they were using the feature. The reviewer now has to go into one or more cycles with the reporter fishing for that information — wasting everyone's time and energy.
Only slightly better are these reports:
<Feature X>
doesn't work — I keep getting<Result X>
from it, which is incorrect.
At least this tells the reviewers what they reporter is receiving… but it doesn't tell them how they got there, or what they're expecting.
So, the following should be your mantra when reporting issues or making feature requests:
Just an FYI for anyone interested: I'll be performing a webinar for this week's Zend Wednesday Webinar series on Zend_Form. You can get details on the webinar and how to register for it at the Zend_Form webinar information page.
I'll be covering the design of Zend_Form
, the basic usage and various classes
and plugins available, and internationalization of your forms. Please join me
Wednesday at noon EST!
I've been working on Zend_Form for the past few weeks, and it's nearing release readiness. There are a number of features that Cal didn't cover in his DevZone coverage (in part because some of them weren't yet complete) that I'd like to showcase, including:
This post will serve primarily as a high-level overview of some of these features; if you're looking for more in-depth coverage, please review the unit tests. :-)