Question

I’m coming from CodeIgniter, and the terminology overlap between it and other MVC frameworks (particularly Zend) is giving me a mental block of some kind.

I want my users to visit http://mysite.com/do/this.

I understand that “do” is the Controller, and “this” is a function (well, method) within that Controller.

My site will have common elements like a header and sidebar; I understand that those go into a Layout, which will be incorporated into the final output.

I want the /do/this page to display three visual blocks of information (I’m deliberately not using the word “modules”). Let’s call them BlockA, BlockB, and BlockC. Maybe one is a list of “new events” and another is a list of “new posts” and another is something else. Whatever. The trick is, these blocks of information will also be displayed on other pages of the site – say, http://mysite.com/did/that.

Both the “did” and the “do” Controllers (and the “this” and “that” methods, obviously) would be arranging BlockA, BlockB, and BlockC differently. Each Controller would have different criteria for what went into those blocks, too – one might be current information, while another might be archived information from the past.

I want to ensure that future programmers can easily alter the appearance of BlockA, BlockB, and/or BlockC without having to touch the code that populates their data, or the code which arranges them on each page.

So my general feeling is that BlockA, BlockB, and BlockC need to have their visual layout defined in a View – but that View wouldn’t be specifically associated with either the “do” or the “did” Controllers. And the code which populates those blocks – that is, queries information from a database, selects the bits that are to be displayed, and whatnot – shouldn’t reside entirely in those Controllers, either.

I started down the path of putting the logic – that is, assembling what will be displayed in each block – into Models. I feel I’m on the right path, there; both the “do” and “did” Controllers can thus summon the block-creation code via Models. But how (and where) do I abstract the visual element of those blocks, in such a way that the visual elements can also be shared by these two Controllers? Do the Models somehow load a View and output HTML to the Controllers (that doesn’t feel right)? Or is there a way for the Controllers to run the Model, get the data to display, and then somehow feed it to a common/centralized View?

I know how I’d do this in CodeIgniter. But… what’s the correct architecture for this, using Zend Framework? I’m convinced that it’s very different than what CodeIgniter would do, and I want to start writing this application with the right architecture in mind.

Answer 1

One small naming thing: /:controller/:action/* => /do/this = this is an action (although also both a function and a method in the controller, action is the proper name)

Your blocks to me sound like “partial views”. There are a few ways to approach this problem, and depending on how the views work, or what information they need to know, you adapt your strategy

Rendering Partials

You want to use this method when you have some view code you want to be used by multiple views. There are two different approaches using the view helpers Zend_View_Helper::render or Zend_View_Helper_Partial* The render($phtmlfile) view helper is more efficient, the partial($phtmlfile, $module, $params) view helper clones a new view, unseting all parameters, and setting the ones you pass in. An example of how to use them:

case/list.phtml:

 <?php
    $this->headTitle($this->title);
    // works because our controller set our "cases" property in the view, render
    // keeps our variables
    echo $this->render("case/_caseListTable.phtml");

case/view.phtml

 <?php
    $this->headTitle($case->title);
 ?><!--- some view code showing the case -->
 <?php if ($cases = $case->getChildren()): ?>
   <h3>Children</h3>
   <?php echo $this->partial("case/_caseListTable.phtml", "default", array(
          "cases"=>$cases,
         )); ?>
 <?php endif; ?>

case/_caseListTable.phtml

// table header stuff
<?php foreach ($this->cases as $case): ?>
   // table rows
<?php endforeach; ?>
// table footer stuff

Custom View Helpers

Sometimes the controller has no business knowing what information is being displayed in the block, and preparing it for your view would be silly, at this point you want to make your own view helpers. You can easily add them to the global view in application.ini:

resources.view.doctype = "XHTML1_STRICT"
resources.view.helperPath.My_View_Helper = APPLICATION_PATH "/../library/My/View/Helper"

I have a tendency to use this method for things that will require additional information from the model not provided by the controller, or blocks of reusable formatting code for the view. A quick example, from a project that I used: Olympic_View_Helper_Ontap grabs the draught beer list and renders it:

class Olympic_View_Helper_Ontap extends Zend_View_Helper_Abstract {
  public function Ontap()
  {
    $view = $this->view;

    $box = Olympic_Db::getInstance()->getTable('box')->getBoxFromName('Draught-Beer');
    if ($box) $menu = $box->getMenu(); else $menu = null;
    $content = "";
    if ($menu)
    {
      $content = "<h1>".$view->escape($menu->title)."</h1>";
      $content .= "<ul>";
      foreach($menu->getItems() as $item) {
        $content .= "<li>".$view->escape($item->name)."</li>";
      }
      $content .= "</ul>";
    }

    return $content;

  }
}

Then in my layout:

<?php echo $this->ontap(); ?>

Your View Helpers can also accept arguments (of course), can call other view helpers (including partial). Consider them template functions. I like using them for short tasks that are required a lot, for instance $this->caseLink($case) generates a properly formatted <a href='/case/2' class='case project'>Project</a> tag.