As a disclaimer, I have to admit that I am no where near the genius of someone like Matthew Weier O'Phinney. If you are, you probably will get little to nothing out of this blog post. In that case, I recommend you read this slideshow on service layers, presented by the lead ZF developer and guru himself.

I read and re-read those slides many times -- but I'm the type of person who doesn't understand something until I've experienced it. I was running into a problem with my MVC apps where I was re-writing controller code for manipulating models quite often. Throw AJAX into the mix and suddenly I'm copying and pasting whole actions almost completely. Throw a public facing web service into the mix and I've tripled my code size. My my, not very pragmatic at all.

Implementing the service layer

So, what's a programmer to do? If you're following the paradigm that controllers are solely for accepting input and rendering output, which I do, then the problem you have -- that is, the code you're copy and pasting -- needs to be re-used instead of re-copied. This is where the service layer comes in for me. The service layer becomes a common API for all your controllers to use - whether through AJAX, Web service, or your plain old webpage controllers.

For example, I have a service I call Service_User. This service contains static methods for reading and writing user models. Example method skeletons look like this:

Now, all I have to worry about in my controllers is transforming the incoming data to correspond to the parameters of my service layer. My admin module, ajax module, and normal member controllers now all touch the very same code.

Why don't I just make my model methods more useful?

This was my gut reaction as well. Indeed, this is what I ended up doing on a whole application. You'll run into a couple of problems:

• These type of methods generally deal with input and output, while the goal of the model is usually to represent something logically in your application.
• You'll usually want methods that deal with collections of models, which doesn't organize well within a model.

I hope this helps clear up some confusion on service layers (well, at least how I use them). Think of them as the API for your application -- if you were going to externalize the internals of your application, what functions would you make? The service layer is the glue in between your models and controllers.

Somewhere along the way I lost sight of the goals. I did not become a programmer because I was amused with math, engineering, or manipulating computers. I became a programmer to create things that have a real impact on the world in some way, even if only slightly. When I first started programming, my code was hideous, insecure, and unmaintainable. But they worked. They had an input, and more importantly, they had an output. And that output did something useful. Why did the culmination of my last year of work have so little output?

The past year has been a great learning experience in other ways, of course. I learned Zend Framework inside and out. I built my own true MVC stack from scratch for learning purposes. I spent tons of time understanding different domain model implementations and formal ORM libraries. And now it's time to put that knowledge to use. I'm switching gears back to being a results-oriented developer.

This made me realize why developer managers push deadlines so hard. Ship your code. Perfect code is not perfect unless it's shipped.
Understanding design trade-offs and cutting features is a skill, not an option.

The biggest suggestion -- and rightfully so, was to minify or gzip the extra controller/action Javascript or CSS file.
It doesn't take a lot of imagination to implement an improvement. There are several easy ways we can prevent the client (our users) from needing to download another CSS or JS file to view a particular controller action.

Firstly, we can get both the CSS and JS files to output in-line instead of loading as a separate file very easily:

File: /application/views/helpers/JavascriptHelper.php

In the CSS helper, we'll use the HeadStyle helper instead of the HeadLink helper:

File: /application/views/helpers/CssHelper.php

If you were using the previous version of the CSS helper, make sure you update your layout to echo the HeadStyle helper. Be aware that the file references (e.g., background images) in your controller / action CSS files will now have a new base URL, so you will need to update accordingly.

The next level - minifying the inline output

The next obvious step is to minify the additional output. My first inclination was to use the CSS/JS minify library aptly titled minify, however, that does a lot more than we need. I'm not a big fan of adding large libraries for the sake of one function, so let's instead explore how we can create exactly what we need within our view helper.

A little more googling gets us to this solution. Sure, it's not perfect, but performing 90% of the necessary packing is good for me.
My CSS view helper now turns into this:

File: /application/views/helpers/CssHelper.php

For the JS packer, we'll use Dean Edward's Javascript Packer that was ported to PHP by Nicolas Martin. You can download the class here:

Download Javascript Packer by Dean Edward

I added the JS packer to /library/jspacker/JavaScriptPacker.php. I modify my JavaScript helper by doing the following:

File: /application/views/helpers/JavascriptHelper.php

The major disadvantage to this is debugging can be a pain when you don't have line numbers or variable names to reference. Thus, I added a conditional statement that only packs the Javascript if not in the development environment:

Presto! Auto-minifying, auto-packing inline Javascript and CSS only when we need it for our controller/actions.

Next steps? I suspect our next step is to add some server side caching so all this parsing doesn't happen in real time at the client's expense. Look for a short part 3 using Zend_Cache very soon.

Questions, comments? Please feel free to leave them below!

As a developer/designer (jack of all trades, master of none, if you will) I tend to stay away from some of the more common developer solutions that take care of a lot of the design overhead (e.g., jQuery UI framework, Dojo, etc). Flexibility is paramount to good design -- boxing yourself into a specific layout for every page is bound to produce a boring, forgettable website. Design is highly underrated to developers, I believe a good aesthetic sense is a skill worth maturing for anyone who develops web applications. After all, you can have the most beautiful underlying code, but if it's presentation is anything short of beautiful it completely loses its "wow" factor.

Full design control usually means large, thousand plus line CSS files that equal serious pain when it comes to maintenance or building upon. If you don't namespace your selectors carefully you'll end up paying for it down the road. And heaven forbid you apply a default HTML tag styling. So, ranting aside, how do you maintain flexibility and still keep tidy CSS and JavaScript? My solution is to keep the very same directory/file structure that is used for the application for my CSS and JavaScript. The best part is by writing a very simple view helper, it's super easy to automate the proper head link and script file inclusions.

Here's what my CSS and JavaScript view helpers look like:

File: application/views/helpers/JavascriptHelper.php

File: application/views/helpers/CssHelper.php

With that done, add the helper to your layout in the section:

File: application/layouts/scripts/layout.phtml

Now, anytime a controller action is invoked it will look for a javascript and css file in the same controller/action file path. In the above examples I've hard-coded the CSS and Javascript parent directories (/public/media for me) directly in to the code, but this would be pretty easy if you wanted to throw it in a config file or something instead. Otherwise just change to your preferred directory and your good to go.

The next thing I'd like to explore is automatically packing/minifying all CSS and Javascript into one file (or possibly outputting them directly to the layout in-line) and then caching the results of that to optimize bandwidth usage. If I ever have the luxury of that being a priority, that is

I did this because the name implied that I am some Zend Framework guru -- which I am not, so I have changed the name to something more fitting. Of course, as I code and learn new things, I will post articles/tutorials here for all. Nothing changes are far as that goes.It felt a little bit arrogant to represent this website and myself as an expert when I am still learning so much from the true experts. Truthfully, my goal is to suck up as much knowledge as I can and then spit out all the good parts. The "tutorials" and "articles" section at the top will remain and I will continue to contribute to both, although there may be more general/opinion posts in the future.

If you want to know what inspired the name, have a read of this famous Joel on Software article.

First, I create a folder called "scripts" in my application directory. This is an ideal location for scripts because it's outside of the Apache HTTP root which means we don't need to worry about remote execution. We can also easily point CRON jobs to this location instead of running some fangled CRON job to cURL a particular URL (Yes, I'm guilty of this, sadly).

Now, at the top of any script we write, add the following:

File: /application/scripts/anyscriptyouwrite.php

This sets our application environment to the "script" environment. Now, we will customize our Bootstrapper when running scripts by editing the index.php in the web root:

File: /public/index.php

Notice, we don't ever call the run() method, so the front controller never gets instantiated. This allows us to explicitly declare each resource we want to setup an environment more ideal for scripting.
Another cool side effect of using the APPLICATION_ENV is we can specify script-specific settings in our application.ini:

File: /application/configs/application.ini

If you dig deep enough, though, you'll find that someone out there has probably tried to do whatever  it is you are trying to accomplish -- or at least something like it. Here's my list of the top resources I use to reach solutions for my Zend Framework problems.

1. The Reference Guide - Duh, right? It's #1 on my list, and it should be #1 on yours. If it isn't, are you sure you're reading it fully? I can't tell you how many newbies I've talked to that simply have not read the appropriate reference guide section on the functionality they are asking about. It's not perfect and it has some holes, but it is by far the most definitive resource.
2. EDIT: As the much respected Matthew Weier O`Phinney points out in the comments, I've forgotten one of the best resources out there: The mailing lists. Take your pick or just sign-up to fw-general@. You may even end up with a reply from the author of the component you're dealing with.
3. Stack Overflow - Stack Overflow is a Q&A site full of knowledgeable developers. My favorite part about Stack Overflow is developers that otherwise have no concrete online identity such as a blog or twitter will respond to posts. There are many knowledgeable "lurkers" who come out of the wood-works and often have clever solutions to problems that I wouldn't find on Google. Also, there are even some ZF contributors such as Bill Karwin who will personally respond to your questions.
4. Surviving the deep end - After I read this, I could barely go back to my Zend apps in progress without completely restarting them from ground up. If MVC was ever unclear to you before reading this, read this now. Especially the section on controllers and models.
5. Zend Framework in Action - Although intended for the Zend Framework 1.0 release, the concrete real-world examples it provides for some of the framework's most core classes (Zend_Controller, Zend_Auth, Zend_Acl, Zend_Db) is still relevant.
6. IRC - This outdated protocol still thrives among hardcore developers, and PHP programmers are no exception. Join the #zftalk channel and ask your question. There are usually attentive and experienced users there who have probably ran into the problems you're facing. Several large ZF contributors also lurk here as well.
7. Twitter - I'll admit, it's not my cup of tea but it's been a great resource for others. Ask your question, throw on the #zf hash tag, and cross your fingers.
8. Blogs. Although most of the relevant ones will popup in a Google search, there's a couple I subscribe to regularly (that you can see on my links section to the right). If it's on my blogroll, it's because I feel any new post they make will be relevant and insightful. Each one is worth checking out.
9. and last but not least... nothing explains the code in more detail than the code itself. One of the most important lessons you can ever learn in programming is nothing teaches you like diving into the code yourself.  Although the task can seem daunting at first, it's often a better solution than an endless Google search or waiting for answer.

Anyways, hope this helps someone. Maybe eventually this site can be added to the list above !

query() - Will return the results of any SQL query.

fetchRow() - Will return only the first row of the result set.

fetchCol() - Will return only one column (the first one if your select statement will be used) as an array.

fetchOne() - Will return only the value of the first column of the first row of the query.

These methods return row objects wherever possible (for query(), fetchRow(), and fetchCol()). You can change this to an array by setting the fetch mode before executing the SQL:

Or, if you just want to get your results as an array in the first place, you can use $db->fetchAssoc($query).

Creating queries programmatically with Zend_Db_Select

A Zend_Db_Select statement produces SQL that is correct based on the adapter you are using. It also takes care of things you probably don't ever bother to do when you write your own queries, such as deliberately expressing all tables along with their columns and properly escaping all table and column names. Zend_Db_Select ultimately returns this query, so usage is simple:

In this case, $db->select()->from('sample') returns the following string:

We can add parameters to our select statement easily:

Which produces:

With a little more research, you will quickly discover that you can perform nearly any non-complex query with Zend_Db_Select.

When to use Zend_Db_Select and writing SQL directly

The first thing you probably took away from Zend_Db_Select (at least I did) is the fact that it makes writing really simple queries way more complicated than they should be.

And, well, you're right. It's hard to fight the instinct that using Zend_Db_Select feels like the right thing to do - it feels like it's the convention that a good programmer is supposed to follow. The reality is, for your application, you probably don't need to use it. Here's the list of conditions I came up with where I use Zend_Db_Select over writing the query directly.

• You are writing an application that needs to run on top of different types of RDBMS?
• You are writing a piece of code that you want to use in several different applications where the environments are unknown.
• You are writing a query that will be modified based on different logic conditions.

For the average application, you probably won't find yourself needing Zend_Db_Select that much. That said, when you do need it, nothing can beat it for the level of abstraction it provides.

Let's go over the quick list of why it's my fave:

• It automatically wraps PDO extensions and normalizes them as best as possible across different types of databases (in simple terms: change from a MySQL database to an MS SQL or PostgreSQL database with minimal code change)
• It sanitizes data input for you automatically (as long as you use it correctly)
• You can quickly grab results in array or object form without performing any post query operations.
• Provides methods for programatically creating queries

On top of that, it's easily decoupled from the rest of the library. Let's start out by ripping out Zend/Db.php and the Zend/Db folder and dropping it in our app.

Initializing the database connection

Now, in our settings / boilerplate file let's initialize the database adapter. The database adapter uses a lazy connection (meaning it doesn't actually connect to the database until you perform a query with it) by default. This makes the application settings a perfect place to setup our database object.

$db = Zend_Db::factory('Pdo_Mysql', array(

    'host'             => 'localhost',

    'username'         => 'database_username',

    'password'         => 'database_password',

    'dbname'           => 'database'

));

That's easy enough. If the application is simple and you plan on referencing the $db variable every time you want to make a query, you can stop right there. If you plan on using the database connection within a function or class scope, you don't have to re-initialize it every time (or use icky global variables). Zend_Db_Table comes with a static function for setting the default database adapter.

require_once('Zend/Db/Table.php');

Zend_Db_Table::setDefaultAdapter($db);

And now within our classes or functions, we can easily call it at any time:

class MyClass {

    private $db;

    function __construct() {

        $db = Zend_Db_Table::getDefaultAdapter();

    }

}

Presto. Persistent database object any time we need it in our application / script.

It wasn't too tough to do either. Replace your Geshi library with this one or, if you want to use the same WordPress plugin as I'm using, download the entire CodeColorer plugin and extract to your WordPress plugins directory.

Note: I probably have not added all Zend class documentation links - I didn't recurse through the whole ZF library and add every class because most actually don't have a dedicated manual section. In most cases I only added the main parent class. I'll try to keep this as updated as possible with new ZF releases.

Last file update: January 5th, 2010

Download CodeColorer WordPress plugin
Download only Geshi library