It shouldn't be like that.
Its an architect level discussions the implementation is not an issue.
It may be the right oop way to use some interface (will be in use in cake2.0
I hope) to the view but I am sure it shouldn't be the model interface
On Wed, Nov 17, 2010 at 12:46 PM, Joshua Muheim <psybea...@gmail.com> wrote:
> Yeah, I like this discussion. Nice to have different views on the same
> issue and learn something. Thank you, guys!
>
> I guess, what RoR guys often forget, is that Ruby is a lot more a
> powerful language than PHP, so it can do magic that PHP can't and so
> for PHP frameworks one solution is better than for Ruby frameworks and
> vice versa.
>
> On Wed, Nov 17, 2010 at 8:44 AM, Zaky Katalan-Ezra <procsh...@gmail.com>
> wrote:
> > There is a known debate about if the controller should know about the
> model
> > and view while the model and view should not know about each other
> > Or, the view should know about the model for update purpose for example.
> > I prefer the the first approach but I understand the other is ok too.
> >
> > Considering the fact that controller may have several models and several
> > views it should hide the data gathering process from the view.
> > For example:
> > You have a users model controller and view.
> > Then you decide to extract the email column to a different profile table.
> > All you need to do is playing with your models and controller and do
> nothing
> > with the view.
> >
> > But if you passed the model to the view you need now to pass the new
> profile
> > model and make changes to your view.
> >
> >
> >
> > On Wed, Nov 17, 2010 at 6:20 AM, 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+unsubscr...@googlegroups.com<cake-php%2bunsubscr...@googlegroups.com>For
> >> more options, visit this group
> >> at http://groups.google.com/group/cake-php?hl=en
> >
> >
> >
> > --
> > Regards,
> > Zaky Katalan-Ezra
> > QA Administrator
> > www.IGeneriX.com
> > Sites.IGeneriX.com
> > 054-7762312
> >
> > 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<cake-php%2bunsubscr...@googlegroups.com>For
> > more options, visit this group at
> > http://groups.google.com/group/cake-php?hl=en
> >
>
> 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<cake-php%2bunsubscr...@googlegroups.com>For
> more options, visit this group at
> http://groups.google.com/group/cake-php?hl=en
>
--
Regards,
Zaky Katalan-Ezra
QA Administrator
www.IGeneriX.com
Sites.IGeneriX.com
054-7762312
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
