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:

• 1.8 Preview Release (zip)
• 1.8 Preview Release (tarball)

This marks the second in an on-going series on Zend_Form decorators.

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.

In the last two entries in this series on models, I covered using forms as input filters and integrating ACLs into models. In this entry, I tackle some potential infrastructure for your models.

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.

I've fielded several questions about setting up an autocompleter with Zend Framework and Dojo, and decided it was time to create a HOWTO on the subject, particularly as there are some nuances you need to pay attention to.

Just about every day, I have an idea for a blog post, and most days, by the end of the day, I just don't have the time or energy to actually write anything up. The inner writer in me screams, "no excuses!" while the aging adult in me whispers, "time for bed, dear."

So, to keep my hand in the game, here are a few things running through my head, or that I'm working on, or that I'll be doing soon.

Today, we released Zend Framework 1.7.0. This release features AMF support, JQuery support, and Twitter support, among numerous other offerings.

For this particular release, we tried very hard to leverage the community. The majority of new features present in 1.7.0 are from community proposals, or were primarily driven by community contributors. For me, this represents a milestone: ZF is now at a stage where fewer and fewer core components are necessary, and the community is able to build off it and add extra value to the project.