views:

436

answers:

2

I'm creating a library of display objects for our application. They render the html of a lot of the common objects (users, conversations, messages, etc) in various views. By views I mean the object can spit back different 'zoom levels' of itself with different markup.

Some display objects contain other display objects to render eg. a user list object renders user objects in a certain view (this particular view spits them back in list items so they fit into the list)

I'm trying to move these into the proper way of doing things in ZF, but I can't decide if these should all be view helpers, or if they are all view scripts/partials.

Just making them view scripts and rendering them with ->render() seems a little dirty because any information or parameters I want to pass to them has to be assigned to the view object.

Partials seem a little more correct, except not sure if its proper to be doing display logic in these (if 'showNotificationStatus' is passed as a parameter, render this span). Or if its kosher for partials to render other partials (a user list rendering the user object).

View helpers seem like possibly the right way to do it, but I don't know if that is overusing view helpers. Each object could be a view helper and accept a objectview parameter so it knew what zoom level/container to render itself in, or each objectview could even be its own helper (so there's no big switch statement inside an object). One nice thing about the views is you can pass parameters and it still has access to the view context if you need something from that level.

Most of these are going to be accepting models, with a few requiring some extra parameters to know what to do (eg. showNotificationStatus from above). What's the proper tool for this?

A: 

Helpers are for logic (e.g. convert object to array), partials are for decorating logic (display recursive array as a <ul> tree).

Remember, you may also use $this->render('anyfile.ext') or include() as well.

takeshin
One thing that blurs that line for me, is there are helpers that ship with ZF that are precisely for creating html elements from provided data. See all the form helpers on http://zendframework.com/manual/1.10/en/zend.view.helpers.htmleg. formCheckbox creates a checkbox with data you pass to it
Bob Spryn
Helpers which may have different HTML output, use `setPartial()`. When running partial is too expensive (or you are sure it output will be each time the same), it's easier just to hard code HTML in the helper. Just implement `setPartial()` with fallback to the default markup, if partial is not set.
takeshin
+1  A: 

One of the core ideas of partials is that they're meant to be as re-usable as possible - hence why they have their own variable scope. I like to use partials as fairly dumb containers for small bits of HTML. No major logic other than a few if() or foreach() statements.

If I need serious logic - I use a helper. Helpers should be responsible for dealing with logic and calling render methods. I know in the Rails world, helpers tend to encapsulate little bits of logic, like handling the construction of links or image tags. This is great, but I don't think there's any harm in making them more complex in ZF. I essentially use them to translate my business objects into views.

I think the best way to use both partials and helpers is have helpers set up the data, then pass it into partials. This way your HTML stays very easy to maintain (and I suspect that every time someone types echo "<a href='". $my_link . '"/>" a kitten dies somewhere).

EDIT (to elaborate):

The thing to remember about helpers is that they can be treated like normal classes, use a constructor with arguments and have private members. So when you instantiate a helper, you can a business object, and then have multiple methods that render HTML (via partials).

So in my view:

<?php $helper = $this->_helper->MyUserHelper($users); ?>
<ul>
  <?php $helper->user_list(); ?>
</ul> 

Here, the user_list() method returns a collection of <li> elements with all the proper data in them.

My helper might looks like this:

class MyWidgetHelper 
{
  private $_widget;   

  public function __construct($users)
  {
     $this->_users = $users;
  }

  public function user_list()
  {
     // do any necessary logic here
     // then return the html that gets rendered. 
     // you can call a partial from here, and it just returns an HTML string.
     return $this->_view->partial('partials/_user_item.phtml', array('users' => $users)
  }
}
Bryan M.
Bryan I think this is really good information. Any chance you can elaborate a little? Say you have a business object that can be represented at a bunch of different zoom levels (of detail). Do you have one helper, that renders different partials based on a parameter you pass? Many helpers with corresponding partials? Basically are you looking at generally a 1 to 1 relationship? And is it cool for partials to leverage other view helpers? (Imagine a conversation, that contains a list of users inside of it. Need to render the users inside the conversation partial.)
Bob Spryn
I added to my response a above with an example. In my example, I use helpers to control partials, but I don't see why you couldn't do it the other way around. I just prefer to keep my HTML as free of php logic as I can.
Bryan M.
Outstanding. Thanks a bunch Bryan!
Bob Spryn