Re: [fw-mvc] Pattern / example?

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