My Blog

Through reading a few blog posts over the last year and my own trial and error, I’ve developed a way of using the flashMessenger Helper in ZF that works out really well for me. (Note: if anyone knows the original blog post that I got some of the view helper from, please comment!).

Objective

• Use FlashMessenger to store both success and failure messages and denote them as such.

Using FlashMessenger in the Controller

Now, we’re going to change the way we assign messages in the controller. Make an array of the message with a key of the type, and a value of the message. You may want to use ‘success’ and ‘failure’: in some controller…

1

Next, create a View Helper

Create the following view helper. I placed mine here: application/views/helpers/FlashMessages.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

The output is initially blank. This is because we will always ‘blindly’ call this in our layout later. Then, the messages are retrieved from the flash messenger using the getStaticHelper method to retrieve the FlashMessenger helper (and call its getMessages() method). If it has content, output is appended with a UL with an ID of messages (this is for css styling later). Then, each message is looped through and added to an LI element. The ‘type’ is the class of that element, and the message is the content. (Note: since this is an array of single arrays where neither the key nor the value is known, that is the reason to use key() and current()). Finally, output is updated with the closing UL tag.

Use this in Your View

I technically put this call in my layout towards the top of my content:

1

I also modify my CSS to have styling of green for the #messages li.success and red for #messages li.failure.

Google Charts has a QR code generation service (here are the details). I decided that I wanted to create my own ZF View Helper to display these on my pages. This version that I am going to show just returns the properly formatted URL for the charts API. The view must create the img tag around it.

The Code for Google QR Code

Place the following code in your view helpers location. For example… application/views/helpers/GoogleQRCode.php.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

First thing is the function declaration. It will accept some data to encode. By default, the width and height are 100px. This can be overridden with the helper call. Next, the URL for the Google charts API is defined. Notice that this version is https – just in case its used on SSL websites. Next, the parameters to the API are built. The ‘cht’ or chart type is ‘qr’. The chart size or ‘chs’ is the integer width by the integer height. Finally, the ‘chl’ value is the data. Finally, the URL is appended with the value of the results of http_build_query() of the url parameters. Finally, the URL is returned from the method.

IMPORTANT NOTE: In the spec, it says that the data should be url encoded. The view helper is not doing that when it creates the parameter array. This is handled by http_build_query.

To use this in your view, you may have the following code: application/views/scripts/index/index.phtml

1
2
3
4

Future options: At some point if I tend to use this more often, I might replace this entire view helper with a more model based application. The view helper will still call the model, but the model will handle retrieving and caching these QR codes. If the Google Charts API is not responding, previously generated QR codes will still be available that way!

Today I was reviewing some old code I wrote in Zend Framework. One of the things I was doing in the Bootstrap.php file was creating an function called _initViewSettings(). In here I set a bunch of values for the xhtml version, the css files to include, etc. Now I realize my mistake:

Do not include functions in the bootstrap.php file that will never be used by command line.

Since Zend Framework projects can be launched via command line and via web page, there needs to be no overlap in the bootstrap.php file between uses. There should only be bootstrapping code – that is to say, things required in order to access or initialize global resources. The view and its settings are not a global usage object.

Instead, create a front controller plugin.

Front controller plugins are launched whenever there is a request as a webpage. They are not ran when a CLI program is ran. (Don’t get this confused with definition and initialization. The bootstrap class has to define and initialize them – it just doesn’t invoke them).

Let’s see this in practice.

Before: application/Bootstrap.php

1
2
3
4
5
6
7
8
9
10
11
12

Now, afterward, make sure front controller plugins are defined, and then create a front controller plugin.

After: application/Bootstrap.php

1
2
3
4
5
6
7
8
9

After: application/plugins/ViewSetup.php

1
2
3
4
5
6
7
8
9
10
11
12

Remember, always remove non-essential code from the bootstrap process.

Theme systems are very common in projects written on Drupal, Joomla, and WordPress. I didn’t see much out of the box support for themes in Zend Framework at first. However, I was wrong. It’s pretty easy. The only real decision I had to make is if I want to make themes that extend a default theme – or themes that are simple and on their own / totally encapsulated. I will do the encapsulated version – but give some pointers on how you would do the other version, too!

Make a Front Controller Plugin

Since themeing is something that is only specific to the view system that is rendered by a web page request, we’ll make a front controller plugin. I’m not creating this functionality in the bootstrap class because command line scripts don’t need to run this, only web requests (which happen to begin with the front controller).

However, we do have to register our front controller plugin using the bootstrap class. First, I’m going to register my new plugin. The plugin will be called Template. It will be located at application/plugins/Theme.php. (Note: the default ZF loader knows this location).

application/bootstrap.php

1
2
3
4
5
6
7
8

This method simply registers a new plugin named Application_Plugin_Theme() to the front.

Pick your Theme

I’m going to create only one theme for this demonstration.

Name: My Simple Theme
Folder: simple

For the purpose of our demo, we’ll just hardcode this as the ‘chosen’ theme. You may have some sort of theme management solution.

Plan your file system

Next, I know that I’m going to have multiple view folders: one for each theme. Additionally, I’m going to have to have different folders inside of the public folder to support this.

Our initial views folder:

application/views/scripts
application/layouts
public/images

Instead, if we’re going to create assets for My Simple Theme, the folder paths will now be this:

application/views/simple/scripts
application/layouts/simple
public/themes/simple/images

Any specific content is placed in these folders instead.

Create the Front Controller Plugin

Our plugin will be called Application_Plugin_Theme. I’ll register a routeShutdown hook because this is one of the last things we have to do or figure out. Certainly don’t want to do it on every call in the loop nor do I want to do it before a redirect could occur.

application/plugins/Theme.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

The first three lines of this are the theme management hardcoded portion I created. It is important later, however, in the view helper we’re going to create to have access to the $theme object — hence the Zend_Registry call.

First, access the bootstrap. Next, set the base path of the main view object by including the theme folder name in it. Notice how this is setBasePath() – if you wanted to create a system where templates inherit other ones, you may use addBasePath(). The setBasePath() resets the paths array internally and then adds the paths for /scripts and /helpers.

Next, if you are using layouts, which I’m sure you are, you basically do the same thing with the layout object.

With this plugin, now all items will load from their proper folders. Just as an example – say you are using the simple theme.

url: /blog/viewAll
controller/action: BlogController::viewAllAction()
layout: application/layouts/simple/layout.phtml
view: application/views/simple/scripts/blog/viewAll.phtml

Last step: View Helper

Since there are different public assets depending on what template that was used, we created the multiple folders in the public folder. For example, you may have public/simple/images, public/simple/js, etc.

Since this view helper is going to be shared among all of our views, however, we can put it up a level, outside of the theme root. The views folder may now look like this:

application/views/helpers
application/views/simple/helpers
application/views/simple/scripts

Create a new Helper called Application_View_Helper_Theme inside of the file: application/views/helpers/Theme.php

1
2
3
4
5
6
7
8
9
10

Now, modify the front controller plugin to “add” not “set” a new helper script path. Add the following code:

application/plugins/Theme.php

1
2
3
4
5
6
7

Now, your zend framework project will look in the regular scripts folder as well as your theme folder for view helpers.

How might we use this?

Old view:

1

New view:

1

This will render the theme URL of /themes/simple/images/smiley.gif.