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+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
