Top listings

Zend_Db_Table is a very, VERY handy class for working with databases. It has come up in numerous posts on this blog. But I’ve always felt that for a complete model implementation there was something missing.

After reading many tutorials, I decided it was time to write one myself. Not because the ones out there are bad, most of them are really good reads, and will get you started with the Zend Framework in a jiffy. But in my opinion they take a wrong approach towards getting people started in application development.

I’m a great fan of using “decent” template engines, and try to avoid writing views in php. I don’t want to discuss the reasons behind this in detail right now. I just believe that limiting yourself to a small set of template tags makes you think more about structuring your output and separating logic from design. Which is a good thing.

Since the first time I really saw and understood what Flash was and did, I've been jealous of what Flash designers could do. Beyond just the cute animations for banner ads and games, Flash designers have always had a much more fine-grained control on their environment that HTML allows for. Besides my innate inability to design anything like a usable interface, the main drawback that has kept me from exploiting Flash is I never could get my head around the "Movie Timeline" metaphor for programming. As we say back home, "It just ain't right."

Half the trouble in conceiving of a extended View system is agreeing on terminology. Everyone has their own idea of the basic concepts, but without names we're left with vague descriptions. Here I'll throw out some terms, some borrowed, others mangled slightly, the rest fairly obvious. These terms all describe specific rendering processes. Methods of capturing presentation logic in neat parcels which carry specific consequences, follow object oriented practices, and provide (we dare hope) commonly sought functionality.

A tutorial about using Zend_Translate to write multilingual applications

It's been a while since I continued this series. Unfortunately real life workloads are unforgiving of the best of intentions ;-). Part 5 of our series takes a small time-out from approaching a Composite View solution to reusable Views to take a peek at a simpler approach useful for simpler types of web applications. As we've discussed previously Composite Views allow the nesting of reusable View elements, effectively building a View based on a hierarchy of Views. But often there are simpler solutions to simpler problems. One such solution is the Two-Step View pattern, sometimes called Layouts if implemented in a specific way (as we do below!).

In the previous two parts of this series of blog posts, I've been looking at the task of implementing complex views with the Zend Framework. Part 1 looked at what complex views are, what support for complex views the Zend Framework offers out of the box, and a reference to two design patterns useful in adding further support: View Helper and Composite View. In Part 2, I tackled the View Helper design pattern.

In parts 1, 2 and 3 I've been taking a look at the Zend Framework and putting together a broad picture of a potential implementation to add support for complex multi-part web pages. This refers to the practice of building a web page in an application from a number of common reusable elements. An example of such elements include header sections, footers, menu bars, widgets, etc, which surround the main content returned by any client request. In Parts 2 and 3, I introduced two useful design patterns for this purpose: Composite View and View Helper.

Over the last week a lot of the activity on the Zend Framework mailing lists has revolved around the introduction in 1.0.0 RC1 of the ViewRenderer action helper. As of RC1 this helper has been enabled by default. Lot's of queries have been raised about how to disable, modify it, and generally how current applications can be made to work with the ViewRenderer.