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).
I'm speaking at PHP Quebec this week. While I live a scant 1.5 hours away from the venue, this is the first I've been to the conference. The snow gods have declared their wrath already, but I plan to thwart them and drive up to Montreal this evening regardless.
I'm giving two talks and participating in a panel discussion this week. The first talk is entitled "Practical Zend Framework Jutsu with Dojo," and, while it may look like a familiar topic of mine by this point, I've spent the last several days reworking the talk entirely, and am very much looking forward to presenting it tomorrow. (My copy of "Presentation Zen" could not have come soon enough! and that's all I'll say about that.)
On Friday, PHP Quebec has introduced a "Framework Bootcamp" track, including sessions by myself, Fabien Potencier of symfony, and Derick Rethans representing eZ Components. My talk that day is entitled "Zend Framework Little Known Gems." While hardly a completely original talk (Aaron Wormus did a "Hidden Gems" series of posts for DevZone a couple years back, and Zend's own Shahar Evron did a similar talk at last fall's IPC), this will be my first time doing a Zend Framework talk on something other than the MVC stack (or how to use components with the MVC stack). Leaving my comfort zone, so to speak.
Towards the end of the day, Fabien, Derick, and myself will be corralled onstage together for a "Framework Comparison".
If you're headed up to PHP Quebec this week, I look forward to meeting you or seeing you again!
I'm really not sure I understand these "seven things" or "tagged" memes, but I'm going to give it a shot, after Keith Casey did a drive-by tagging of me on New Year's Eve.
So, without further ado, seven things you may not know about me...
That time of year again -- wrap-up time. Each year, it seems like it's the busiest ever, and I often wonder if it will ever slow down. As usual, I'm restricting myself to primarily professional activities out of respect for the privacy of my family.
The short, executive summary:
Read on for the gruesome, month-by-month breakdown.
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.
In my last post, I discussed using Zend_Form as a combination input filter/value object within your models. In this post, I'll discuss using Access Control Lists (ACLs) as part of your modelling strategy.
ACLs are used to indicate who has access to do what on a given resource. In the paradigm I will put forward, your resource is your model, and the what are the various methods of the model. If you finesse a bit, you'll have "user" objects that act as your who.
Just like with forms, you want to put your ACLs as close to your domain logic as possible; in fact, ACLs are part of your domain.
A number of blog posts have sprung up lately in the Zend Framework community discussing the Model in the Model-View-Controller pattern. Zend Framework has never had a concrete Model class or interface; our stand has been that models are specific to the application, and only the developer can really know what would best suit it.
Many other frameworks tie the Model to data access -- typically via the ActiveRecord pattern or a Table Data Gateway -- which completely ignores the fact that this is tying the Model to the method by which it is persisted. What happens later if you start using memcached? or migrate to an SOA architecture? What if, from the very beginning, your data is coming from a web service? What if you do use a database, but your business logic relies on associations between tables?
While the aforementioned posts do an admirable job of discussing the various issues, they don't necessarily give any concrete approaches a developer can use when creating their models. As such, this will be the first in a series of posts aiming to provide some concrete patterns and techniques you can use when creating your models. The examples will primarily be drawing from Zend Framework components, but should apply equally well to a variety of other frameworks.