As Nate said, original MVC was intended for desktops apps (it comes
from smalltalk). View was associated to a model trough the Observer
pattern, where model was in charge to tell the view when it's status
has changed. Controller was an artifice to make the user able to edit
data in view (using gui widgets) and then it pushes the changes to the
model.

Actual MVC in frameworks like CakePHP is something else, but it works
this way, and has proven to be a really good way to structure web
apps, so bear with it.

More on MVC: http://www.martinfowler.com/eaaDev/uiArchs.html

On Mon, Mar 3, 2008 at 2:34 PM, nate <[EMAIL PROTECTED]> wrote:
>
>  Not true.  If there is a "most important" tier in MVC, it is arguably
>  the model, which is your domain entities, which should encompass the
>  bulk of your application's business logic.  The controller simply has
>  the unglamorous job of shoveling data back and forth between your
>  model and view.
>
>  The important thing to remember, however, is that MVC is a *pattern*;
>  patterns have many implementations, and there's no one right one (that
>  doesn't mean that there aren't many wrong ones).  MVC was first
>  developed almost 30 years ago, and there have been many iterations on
>  it since then, the most notable difference from the original being
>  that it's now used in web applications, whereas it was first designed
>  for desktop apps.
>
>
>  On Mar 3, 11:00 am, "Kjell Bublitz" <[EMAIL PROTECTED]> wrote:
>  > "the view in turn, asks the model for some data to display it"
>  >
>  > This sounds to me like it's an (bad) explanation past the controller.
>  >
>  > Anyway, the view never asks anything from the model. The view is the
>  > final stage (a format, if you want). The most important thing in MVC
>  > is the C. Without the controller it would be sorta procedural and so
>  > the whole object model would be useless.
>  >
>  > The example you gave is an optional one. 99% you wont need to use
>  > requestAction if your controllers and model relations are well thought
>  > out.
>  >
>  > Basicly it goes like this: request -> load controller -> load models
>  > -> call action (using models) -> assign data -> render view.
>  >
>  > And requestAction does nothing else. So there is no direct
>  > Model<->View connection, even so it looks like that. As you can see by
>  > the URL (first param) it calls the "news" controller and the "view"
>  > action - not any specific model
>  >
>  > HTH
>  >
>
>
> > On Mon, Mar 3, 2008 at 4:31 PM, djiize <[EMAIL PROTECTED]> wrote:
>  >
>  > >  If Views directly ask Models to have Data:
>  > >  1- what is Controllers' purpose?
>  > >  2- how do you do business Logic with your data?
>  >
>  > >  On 3 mar, 12:32, Marcel <[EMAIL PROTECTED]> wrote:
>  > >  > Hi!
>  >
>  > >  > I've been doing some research about MVC implementations in different
>  > >  > frameworks. Now in allmost every book I have on my desk it says
>  > >  > something like 'the view in turn, asks the model for some data to
>  > >  > display it'. In cake I have noticed (if I'm correct) the controller is
>  > >  > asking data from the model and that data is then passed to the view.
>  >
>  > >  > Example: $newsItem = $this->requestAction("/news/view",
>  > >  > array("id"=>1));
>  >
>  > >  > My question is why this kind of implementation? It seams to be a bit
>  > >  > of double work because having that kind of intermediate 'layer'
>  > >  > between model and view.
>  >
>  > >  > Just curious ;-)
>  >
>

--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to