Re: [fw-mvc] Pattern / example?

I was assuming that his setDisplay method would be picking up either an instance or would be using a string to determine which class to instantiate. Please correct me if I'm wrong, however my understanding of DI is that the implementation (usually in the form of an interface) is passed into the object (at least in its simplest form). His approach seems to suggest that that's what he's trying to do. I think we're all in agreement that this violates a separation of concerns.

Hector, your example illustrates this perfectly and judging from Ed's description, I think that's what he's trying to accomplish (although I agree that the premise makes the pattern unwarrented).

-
Jon

On Wed, Jun 3, 2009 at 6:35 PM, Hector Virgen <djvirgen@gmail.com> wrote:

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