On May 8, 2006, at 1:51 PM, calzone wrote:
>
> Reading the manual:
>
> Chapter 6, "Models," in the first section shows an example of a model
> with two methods, hide() and unhide().
>
> Chapter 18, "The Cake Blog Tutorial," Sections 9 and 11 show how to
> add() and delete() posts. The methods are added to the controller.
>
> Why are these methods in chapter 6 in the model instead of the
> controller... or, vice-versa, why are the methods in chapter 18 in the
> controller instead of the model?
Because these are model-specific, data changing operations that are
useful to place in the model. Models are a way to interact with your
data source.
User added model functions are there to provide faster access to data
related operations (in this case, "hiding" and "unhiding" a Post).
User added controller functions provide access to application logic.
The add() function in a controller provides a view to the user,
allowing them to interact with the system.
> More important than an answer to this specific comparison, I'm
> interested in understanding the basic strategy or thought process that
> we need to apply when making these kinds of decisions. Understanding
> where different functions and bits of code are going to be put under
> Cake will take me a long way.
>
> And does my question reveal a void of understanding regarding MVC;
> i.e.: is this a standard practice question or a cake question?
Yeah, I'd read up on MVC and ask some clarifying questions if you
have any. It seems you might be confused as to the roles of Models
and Controllers in the pattern. The questions you are asking seem to
be along the lines of the how's and why's of MVC.
>
> chris
>
> (On a somewhat related note, my initial reaction to the Cake Blog
> Tutorial when I implemented it last week was that it felt "wrong" to
> use any php code whatsoever in the thtml files; I expected to see
> usage
> of {FIELDS} inside .thtml. I'm not trying to debate anything, but
> I am
> curious about the high-level design decisions that took place, and to
> understand what makes Cake tick, the philosophy of Cake. The Basic
> Concepts chapter doesn't quite go that far in depth. I'd be most
> grateful to anyone willing to indulge me on this.)
If you're used to Smarty or other "templating engines," the curly
brace format might seem more familiar. Again, you might want to read
up on MVC here. The code in views should be purely *presentational*.
Because PHP already does a great job at view code, Cake just assumes
that users will just use PHP to accomplish that, rather than some
pseudo-template language like Smarty uses. People already know PHP,
so why use something else? (You can extend the View class to use
Smarty if you so choose, however.)
Presentational code is just logic used to format data, not manipulate
it. If you've got code in your view that is coloring a status field
based on it's content, looping through records to display them in a
table, you're following MVC. If you're trying to manipulate models in
the view or otherwise manipulate data handed you from a controller,
you're probably going to run into trouble later on.
-- J
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---
