Re: [fw-mvc] Pattern / example?

Dependency injection would probably be more like this:

$view = new Zend_View();

$Person->setView($view);

$Person->display();

The $Person object would use the view to render itself, which can be any type of view that implements Zend_View_Interface. The Person object would then look something like this:

class Person

{

    private $_view;

    private $_viewScript = 'person.phtml';

    public function setView(Zend_View_Interface $view)

    {

        $this->_view = $view;

    }

    public function display()

    {

        $this->_view->person = $this;

        return $this->_view->render($this->_viewScript);

    }

    /* ... */

}

But this still leads to another problem: it assumes the output will always be html regardless of the view that's passed in.

In order for a model to be able to render itself, it must be aware of the context in which to render itself.  In that case it would be best to pass in a view renderer object (like the action helper) that is aware of the view's context. However, I would wan't to tie a model to a controller helper -- that would prevent the model from being able to render itself without using the full-blown MVC components of ZF.

-Hector

On Wed, Jun 3, 2009 at 3:14 PM, Abraham Block <atblock@gmail.com> wrote:

That is most certainly not Dependency Injection! In fact Dependency Injection is meant to get away from code like that.

On Wed, Jun 3, 2009 at 6:04 PM, Jon Lebensold <jon@lebensold.ca> wrote:

Looks like dependency injection, which is fine but then I don't think you're dealing with what people typically call a Model (which BTW is a misnomer for so many reasons).

It sounds like you're trying to build your own inversion of control implementation in your application domain. The Zend notion of a Model is usually coupled to Zend_Db_Table which is really an object representation of your database tables. My contention comes from the terminology in the Zend context, where a the Model_* namespace is used (by Zend convention) for Db_Table_* objects and so developing a DI implementation in all your models would be a mix of concerns.

If you do take this route, I'd be interested in how you design your various models.

my 2 cents...

On Wed, Jun 3, 2009 at 5:49 PM, Ed Lazor <edlazor@internetarchitects.biz> wrote:

Hi Jon =)

It seems like you're recommending an approach I've been using:

echo $this->displayPerson($Person);

As compared to the new approach of:

$Person->setDisplay('HTML');
echo $Person->display();

In this new approach, the model's display method passes the model's
data to an internal component (another object) that is responsible for
converting the data into a new output format - which the display
method returns.

In psueo-code terms, setDisplay ends up looking something like this:

public function setDisplay($format) {
   $this->_display = OutputFactory::getInstance($format);
}

and the display method ends up looking like this:

public function display() {
   return $this->_display($this->toArray());
}

That way the responsibilities are maintained separately and you the
OutputFactory can be used anywhere?

What do you think?

-Ed

On Wed, Jun 3, 2009 at 1:51 PM, Jon Lebensold<jon@lebensold.ca> wrote:
> Hey Ed,
>
> usually a Model's responsibility does not include how it's viewed (think of
> a PersonModel that appears in an XML dump, a JSON web service and on an HTML
> page). I would suggest writing a view helper that would accept a certain
> kind of model that implements a collection of properties / methods in an
> interface so that my view code could be handled by an object that would only
> have that concern.
>
> Best,
> -
> Jon