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.
I announced this earlier in the year, but for those that missed it, I'm speaking at php|tek next week.
I'll be co-presenting a workshop entitled Practical SVN for PHP Developers along with the lovely and talented Lorna Jane Mitchell. In a way, it's a continuation of the unconference session we did together at ZendCon08, and will provide much more in-depth information on the subject -- including how to create and organize your repositories, branching and tagging strategies, how and when to commit, as well as more basic usage of subversion for day-to-day use.
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
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.
I'm an unabashed Vim user. It has been my primary editor for over seven years now, when I switched to it to make it easier to edit files over SSH. At the time, I made myself use it exclusively for a month so that the habits would be ingrained, and took the time to go through vimtutor as well as to order and read Steve Oualline's Vim book. And when I say "exclusively," I mean it -- I switched to using Mutt for email at that time, and also started doing all code development, outlining, and more in vim. And after a month, I realized I didn't want to use anything else.
Ironically, I find myself working for a company that sells an Integrated Development Environment (IDE). As a result, I've done some test runs with Eclipse, Zend Studio for Eclipse, and even NetBeans, to see what features they offer and to see if there would be anything compelling that might make me change my mind.
Being a technical presenter, I've often run up against the issue of how to present code snippets.
The easiest route is to simply cut-and-paste into your presentation software. However, such code is basically unreadable: it's hard to get indentation correct, and the lack of syntax highlighting makes them difficult to read (syntax highlighting helps users understand the purpose of the various language constructs).