New listings

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.

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!).

A tutorial about using Zend_Translate to write multilingual applications

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.

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."

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.

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.

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.

Earlier today, I wrote a little extension to Zend_Db_Table that allows for “custom” fields to be added to it’s rows. When it was done some other ideas came floating up. Why wouldn’t I make my life even easier, by creating fields that don’t output their values directly.

Because I noticed some people find it difficult to understand the routing process the Zend Framework uses by default, I decided to write a little explanation. It’s really easy once you get the hang of it, even though it may seem complicated at first.