Re: Why only pass $data to view instead of model instance?

I guess it all boils down to personal preference then :P

On Nov 16, 8:20 pm, cricket <zijn.digi...@gmail.com> wrote:
> On Tue, Nov 16, 2010 at 9:44 PM, Miles J <mileswjohn...@gmail.com> wrote:
> > Actually that's wrong. If this was a pure OOP framework, then we would
> > be passing the model or some kind of object to the view, but we are
> > not since Cake uses array as its primary data structure.
>
> I didn't mention OOP. But, now that you have, note that View is an
> object. Among its attributes is an array of data. I thought this was
> awkward at first, also, until I realised that it doesn't matter
> because View really needn't have that close a relationship with the
> data members themselves. That is, it wouldn't make much sense to do
> View::getX() or View::getY() when $x and $y are attributes of Model.
> Of course, I'm not going to sell anyone on that argument if they're
> still convinced that Model should be the object passed to the view.
> :-)
>
> > Say you had a method like this in your User model:
>
> > public function isActive() {
> >        return $this->data['User']['active'] == User::STATUS_ACTIVE;
> > }
>
> > Then all you would need to do in the view is:
>
> > if ($model->isActive())
>
> > That cuts out the whole problem of having to manually write that
> > condition every time its used. It also cuts out the need of a helper
> > that handles this function when its unnecessary.
>
> But it's easy enough to adjust the data array in afterFind(), so that
> argument doesn't sway me. Think of $data as an encapsulation of your
> model instance. Not the entire model itself, with all of its behaviors
> and business logic, but the face it should present to the View. So,
> $data doesn't provide an isActive() method but, instead, includes the
> *information* that the View requires.
>
> Another example would be date formatting. Say a business needs their
> dates all formatted 'd-m-Y'. That's something that definitely should
> be handled by the model because, after all, it's the model that should
> deal with business logic. But it's unnecessary to call a
> formattedDate() method when we can just add a 'formatted_date' field
> to $data in afterFind(). Something like that could be put in AppModel,
> in fact. Either way, it's a cinch to just push it onto the array.
>
> (Another site might need to format dates according to users' locale.
> In that case, the logic should probably be handled in the view,
> perhaps with a helper.)
>
> > Furthermore, Cake models are used incorrectly in my opinion. Models
> > should represent a single entity of data (getters and setters for a
> > row in the database), while Cakes approach is a global model to
> > database table relation.
>
> I'd argue that Cake's ORM makes more sense. There are always going to
> be trade-offs when attempting to map objects to relational data, but
> Cake's DB table to array scheme has worked very well so far. Remember
> that the model's $data is not the entirety of the model. It's just the
> encapsulation for the View. If the latter requires more than what's
> been given to it, you simply have to add it in. That's business logic.

Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.

You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en