I've been using Git for around a year now. My interest in it originally was to act as a replacement for SVK, with which I'd had some bad experiences (when things go wrong with svk, they go very wrong). Why was I using a distributed version control system, though?
Several people have pointed out to me recently that I haven't blogged since early May, prior to attending php|tek. Since then, I've built up a huge backlog of blog entries, but had zero time to write any of them.
The backlog and lack of time has an easy explanation: my change of roles from Architect to Project Lead on the Zend Framework team. While the change is a welcome one, it's also been much more demanding on my time than I could have possibly envisioned. Out of the gate, I had to finish up the 1.8 release, and move immediately into planning and execution of the 1.9 release — while learning the ropes of my new position, and continuing some of my previous development duties. Add a couple of conferences (php|tek and DPC) into the mix, and you can begin to see the issues.
A number of people on the mailing list and twitter recently have asked how to autoload Doctrine using Zend Framework's autoloader, as well as how to autoload Doctrine models you've created. Having done a few projects using Doctrine recently, I can actually give an answer.
The short answer: just attach it to
Now for the details.
In my last post on decorators, I had an example that showed rendering a "date of birth" element:
<div class=\"element\"> <?php echo $form->dateOfBirth->renderLabel() ?> <?php echo $this->formText('dateOfBirth[day]', '', array( 'size' => 2, 'maxlength' => 2)) ?> / <?php echo $this->formText('dateOfBirth[month]', '', array( 'size' => 2, 'maxlength' => 2)) ?> / <?php echo $this->formText('dateOfBirth[year]', '', array( 'size' => 4, 'maxlength' => 4)) ?> </div>
This has prompted some questions about how this element might be represented as
Zend_Form_Element, as well as how a decorator might be written to
encapsulate this logic. Fortunately, I'd already planned to tackle those very
subjects for this post!
I'm thrilled to once again be speaking at the Dutch PHP Conference.
Like last year, I'm giving two sessions; unlike last year, these are going to be more advanced. I noticed last year both in terms of audience participation as well as in speaking with attendees that I'd be able to step it up a notch were I to return.
In the previous installment of this series on
Zend_Form decorators, I looked at how you can combine decorators to create complex output. In that write-up, I noted that while you have a ton of flexibility with this approach, it also adds some complexity and overhead. In this article, I will show you how to render decorators individually in order to create custom markup for your form and/or individual elements.
By the time you read this, the Zend Framework team will have released a preview release of 1.8.0. While the final release is scheduled for later this month, this release represents the hard work of many contributors and shows off a variety of powerful new components.
If you're a Zend Framework user, you should give the preview release a spin, to see what it can do:
This marks the second in an on-going series on
You may have noticed in the previous installment that the decorator's
render() method takes a single argument,
$content. This is expected to be a string.
render() will then take this string and decide to either replace it, append to it, or prepend it. This allows you to have a chain of decorators — which allows you to create decorators that render only a subset of the element's metadata, and then layer these decorators to build the full markup for the element.
Let's look at how this works in practice.
I've been seeing ranting and general confusion about Zend_Form decorators (as well as the occasional praises), and thought I'd do a mini-series of blog posts showing how they work.
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.