Zend Framework Route Context Plugin

Bradley Holt — Mon, 11 Jan 2010 09:58:00 +0000

I want to share a simple, yet very useful, custom Zend Framework plugin that we use on almost all of our projects. The plugin (and associated code in the layout file) provides the Zend Framework route context as CSS classes on the body element. This allows us to change the design (using CSS) and/or behavior (using unobtrusive JavaScript) on the page based on the Zend Framework route. For example if the module name was default, the controller name was news, and the action was get then the opening of the body element would like this:

There are some limitations. For example, you need to be careful not to overlap module, controller, or action names. If this is a problem for you then you could preface the class names (e.g. module-default, controller-news, action-get).

The RouteContext plugin hooks into the preDispatch event and creates an array of route context strings. This example simply uses the module, controller, and action names as the route context. Often I’ll add other contextual strings to this array as needed. This array is then assigned to the view. The layout view script then simply implodes this array into the value of the class attribute using a space character as the glue.

Web Design and Web Development

Bradley Holt — Sat, 02 Jan 2010 21:36:00 +0000

Back in October, Jeffrey Zeldman tweeted something that I strongly agree with:

Real web designers write code. Always have, always will. #aea

This sparked many conversations including these two tweets from Chris Shiflett:

According to @zeldman, real web designers write code. (I think he means HTML and CSS, not PHP, Perl, and Python.) What do you think?

I’ve now asked, separately, whether developers and designers should know HTML and CSS. In both cases, most think they should. Interesting.

To which I responded (brackets added):

@shiflett IMHO, the demarcation between web developers and web designers should be POSH [Plain Old Semantic HTML]. That’s what both need to know.

I have a pretty strong opinion about this. You could say that I have the luxury of working with an excellent designer who implements all of his own CSS—even tackling much of the JavaScript coding on websites we build. To be clear: he is a designer, not a developer—working in both print (which is more technical than you might think) and web.

The typical process is summarized well in Marco Tabini’s PHP Advent 2009 post on CSS and Other People:

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.

In my opinion, that process is broken. Why is it assumed that because HTML and CSS are “code” it should be a developer’s job to implement these? Any decent designer is already familiar with the concept of separating presentation and content with style sheets (which are supported in Adobe InDesign, QuarkXPress, and even PageMaker and Microsoft Word). Is learning HTML and CSS, both declarative languages, considered too hard for designers?

Let’s take a look at comps and the dreaded “s” word—slicing. As Marco pointed out, trying to “slice” a comp into HTML and CSS is “sometimes impossible” and “always challenging.” If a designer is only providing a comp, and not the HTML and CSS, it is very likely that the designer does not have a solid understanding of things like progressive enhancement, browser compatibility, and even what is possible on the web.

The use of a comp generally assumes that design is purely visual and that all representations of the web page should look exactly like the comp. How should the content be presented to screen readers, to mobile devices, and in print? Sure, you could provide comps for each of these scenarios but this is not scalable and you quickly risk violating the “One Web” concept. Thinking of a web page through the lens of only one specific visual representation of that page is very limiting.

Do you agree that the typical process is broken? If so, what are the barriers to fixing this process? Do we need better trained web designers? Do organizations need to be educated on how to better structure their web teams? This problem will eventually self-correct. My prediction is that teams with web designers that know HTML and CSS will create better websites and web applications and be more successful than teams using the old process.

Bradley Holt » HTML

Zend Framework Route Context Plugin

Web Design and Web Development