Re: [fw-mvc] Pattern / example?

Thanks for clearing this up Matthew. The new quickstart is miles ahead of what I remember going through when I started with Zend. I also like how the Table-Data Gateway is decoupled from the Model.

On Thu, Jun 4, 2009 at 7:08 AM, Matthew Weier O'Phinney <matthew@zend.com> wrote:

-- Jon Lebensold <jon@lebensold.ca> wrote
(on Wednesday, 03 June 2009, 06:04 PM -0400):

> 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.

Um... no, actually, that's *not* our recommendation. The *_Model_*
namespace is for models you as a developer create. In the recommended
directory structure -- which is reflected in Zend_Application_Module_Autoloader
-- there is a separate component namespace *_Model_DbTable_* for your
Zend_Db_Table classes, which would be used as a data access layer for
your models. You can see this in action in the current iteration of the
QuickStart, where we use a DataMapper to map the models to the data
access layer (which uses Zend_Db_Table).

That said, I agree with you -- your models themselves shouldn't be
renderable, though I will sometimes recommend that your service layer
objects (which consume your domain models) have that capability.

> 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
>
>

--
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/