Straylight Run

I am nothing if not timely. 

Last month, Chris Shiflett proposed an excellent blog revival idea, wherein I am to write a blog in the month of March about why I like blogs.  Of the ones I managed to read, I liked this “Ideas of March” the best. As for me, well, we are halfway through April – but I started this draft in March?  Here were the rules:

1. Write a post called Ideas of March.
2. List some of the reasons you like blogs.
3. Pledge to blog more the rest of the month.
4. Share your thoughts on Twitter with the #ideasofmarch hashtag.

So here goes…

Way before I had a technology blog, I had a blog about local issues.  Local politics, sports, development, you name it.  I started that blog because I had a lot of opinions about development that was happening around me and issues that were balloted, and I couldn’t rob the world of my enlightened positions by keeping them to myself.   Blogs allow anyone with something to say to say it.

Blogs are ultimately social.  Before there were tweetups, there were blogger meetups. And it is very easy to have something to talk about when introducing yourself to someone (“Hey, I really liked your blog about…”).  Twitter has taken that “breaking the ice” concept to new levels, but it I’d much rather have someone come up to me and say that they’ve read my blog rather than say that they follow me.

Blogs are written, and writing is a good skill to practice.  If I have to write to explain something, then I have to know it well.  And with practice, the explanation gets better and clearer. Then other thoughts get better and clearer.  Then the world just gets better and clearer.

Oh, and blogs contain a crapload of useful information that solve all sorts of problems, or just spread interesting news.

In summary, I like blogs because:

1. They give everyone a voice.
2. They help people be more social.
3. They help me improve my writing.
4. They contain a crapload of useful information and news.

To round off the requirements, I pledge to blog more in this month of March, er – how about I just pledge to blog more?  And hopefully my RSS tweeter should get out the hashtag in the title.

🙂

I recently came up a very steep learning curve using the Zend Framework (version 1.11.3). I had used components of ZF in the past with success, but this was the first time I had used Zend_Application for my core MVC.  I am no stranger to MVC frameworks in general, but I struggled with Zend.

My biggest source of confusion was the bootstrap process.  Namely, the autoloading of resources.  Yes, I followed the Zend Framework Quick Start and got my app up and running. Unfortunately, I didn’t actually know what was happening.  Finally, I came across this great question on Stackoverflow about bootstrapping the layout resource that pointed me in the right direction:

The line from application.ini

resources.layout[] = 

is equivalent to:

_initLayout() {}

in Bootstrap.php

Aha!  So now it was clear. There are two ways to initialize a resource in Zend:

1. By adding one or more mysterious lines to your application.ini, or
2. By constructing them with good old fashion code in a method that begins with “_init” in Bootstrap.php.

Option #1 bothers me.  Yes, it’s really cool that you can bootstrap a whole MVC application with no code and only a config file, but IMO that option should not be the recommended way for beginners and that options should most definitely not be used in any sort of “Quick Start” guide.  That sort of magic should be reserved for advanced users.  With a little more exploring, I found the code that initialized these resources in the non-trivial Zend_Application_Bootstrap_BootstrapAbstract class.  And I found all the built-in Zend resources in Zend/Application/Resource, which let me see which resources had which options and how to bootstrap them. 

On to option #2, my preferred way. If I want to initialize the Front Controller, I’ll just put this in the bootstrap file:

    
protected function _initFrontController()
{
    $front = Zend_Controller_Front::getInstance();
    $front->setControllerDirectory(APPLICATION_PATH . '/controllers');
    return $front;
}

If I want to enable and initialize the layout:

    
protected function _initLayout()
{
    $layout = Zend_Layout::startMvc();
    $layout->setLayoutPath(APPLICATION_PATH . '/layouts/scripts/');
    return $layout;
}

I really don’t mind carrying this around to every project.  Then I can make changes in the PHP, and not in an INI file.

Clearly I am not the only one struggling with this. I googled problems heavily and the top results usually contained 3 or 4 of the same question asked on Stackoverflow, each of which I opened in a tab.  I think Zend would benefit with a re-organization of the documentation from the ground up, at least of the starter docs and Zend_Application. They should also post a big, flashing red link to that Stackoverflow question about bootstrapping layout. 

Eventually, other components became clear: Resources, Plugins, Action Helpers, and View Helpers, Modules.  I see real power in using the Zend Framework now, particularly with Plugins and Modules, but only after much pain.

I have created a starter project for Zend projects that contains Bootstrap.php the way I like it, and some other custom classes for logging and error handling.  There is a branch for a starter project with modules and without modules.  (Modules is a different blog post altogether.)

I am embarrassed to say that only somewhat recently did I figure out truly what a layout-based presentation (a.k.a. two-phase render) was all about. I’ve even used them before, and didn’t know why. 

If you can’t tell someone clearly what is the benefit of two-phase render, go and read the Smarty documentation on it right now.  Smarty calls it template inheritance, but IMO template inheritance, layouts, and two-phase render are all the same pattern.