I'm doing a series of articles on various Zend Framework MVC topics for the Zend Developer Zone. Last week, I covered Action Helpers. This week, I cover Front Controller Plugins. If you've ever been mystified by or curious about this subject, head on over and give it a read!
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
X-Requested-With: XMLHttpRequest header, which allows it to conform to
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
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: