Menu
Community /Pin to ProfileBookmark
@NogDogJul 19.2012 — #Can't really add anything meaningful beyond what Jeff said. However, if you've not checked it out already, you might take a look at the CodeIgniter tutorial videos . In particular, the 2nd (and longer) video shows some "real" usage for a very basic blogging system. If you're not interested in using CI, you don't need to pay close attention to syntax and such, just how things get allocated and exchanged between the M, V, and C.@NogDogJul 22.2012 — #The model essentially manipulates your data. This usually includes database access, but it can also include data calculations (such as business rules or, in your case, game rules). However, I see many people [i]only[/i] use the models for database access and end up putting a lot of their data manipulation in the controllers.
The controller is the traffic cop, deciding what to do when a request comes in, which model(s) to invoke, what to send to/read from those models, which view to invoke, and what data to send to the view.
Generally, your controllers and models will always be objects -- especially if you're using a framework that depends on your controllers and models to extend base classes. Within your controller classes, you might have multiple methods which represent different specific types of requests within a general request type. In CI, for example, if your url calls "www.example.com/foo/bar/", it will invoke the bar() method within the Foo class (after invoking the constructor method if there is one).
The view [I]could[/I] be a class, but I don't think I've seen anyone actually do that. It's usually either procedural PHP or a templating system (such as Smarty). You never invoke (or redirect to) the view directly via HTTP -- you always (normally) invoke a controller, which will then invoke the applicable view (internally probably via include() or require()), which allows the controller to make any output variables/objects available for use within the view.
So, after all that rambling, chances are Dog and User would be models: things whose data you want to track and manipulate. Your controllers might include an Action controller, which could include a feedDog() method, a walkDog() method, and so forth. Both methods might invoke the same view, but with somewhat different data that would control what sort of message is displayed to the user, while also displaying the current user and dog stats (common to any action).@NogDogJul 22.2012 — #It does not have to, but it is a common technique. Typically, you can also pass additional parameters that way, e.g "http://example.com/action/walk_dog/1.5 " might be rewritten by the web server so that it is equivalent to "http://example.com/controller/action.php?action=walk_dog&miles=1.5 ". But that is just (?) an implementation detail -- it is not what makes an application MVC or not MVC.@NogDogJul 22.2012 — #In my example, feedDog() and walkDog() are different actions that are initially represented by methods within a controller. However, that does not mean there could not be similar actions within the models (similar in terms of general subject, not in terms of implementation details): you may need a Dog::feed() method for you Dog model to implement the effects, and method within User or some other model (Inventory?) to record the expenditure of dog food resources.
So, your framework would initially invoke your Action controller's feedDog() method, which then itself would invoke model methods Dog::feed() and Inventory::feedDog() (or something like that). Then when all that processing is done, the controller finally would invoke your "status" view (for example).
Question about MVC
I, more or less, “get” MVC when it comes to generic explanations but I’m having trouble applying it to a script I’d actually make.
Okay, picture a browser-based virtual dog game. You know, HTML, jpeg images, CSS, and perhaps a little JavaScript. Each dog would have its own profile page. If it’s your dog, then you could change its details. So, its page would have forms on it, such as a form to change its name. You’d submit the form and some code in the site would process it (check for errors, update the database, etc.)
Would the HTML for the form be considered part of the view or part of the controller?
What about the code that actually processes the code, is that the controller?
Finally, the code that actually updates the database, that’s the model, right?
Please note: What if the form automatically had the dog’s name already in it. For example, if your dog’s name was “Fido” the form to change its name would automatically have “Fido” already typed in it. Is this part of the view? Or is it part of the model because the site had to look in the database to know that’s your dog’s name?
I’m confident I’ll wrap my head around all this eventually ?
Sign in
to post a comment11 Comments(s) ↴
0
@NogDogJul 19.2012 — #Can't really add anything meaningful beyond what Jeff said. However, if you've not checked it out already, you might take a look at the 0
@NogDogJul 22.2012 — #The model essentially manipulates your data. This usually includes database access, but it can also include data calculations (such as business rules or, in your case, game rules). However, I see many people [i]only[/i] use the models for database access and end up putting a lot of their data manipulation in the controllers.The controller is the traffic cop, deciding what to do when a request comes in, which model(s) to invoke, what to send to/read from those models, which view to invoke, and what data to send to the view.
Generally, your controllers and models will always be objects -- especially if you're using a framework that depends on your controllers and models to extend base classes. Within your controller classes, you might have multiple methods which represent different specific types of requests within a general request type. In CI, for example, if your url calls "www.example.com/foo/bar/", it will invoke the bar() method within the Foo class (after invoking the constructor method if there is one).
The view [I]could[/I] be a class, but I don't think I've seen anyone actually do that. It's usually either procedural PHP or a templating system (such as Smarty). You never invoke (or redirect to) the view directly via HTTP -- you always (normally) invoke a controller, which will then invoke the applicable view (internally probably via include() or require()), which allows the controller to make any output variables/objects available for use within the view.
So, after all that rambling, chances are Dog and User would be models: things whose data you want to track and manipulate. Your controllers might include an Action controller, which could include a feedDog() method, a walkDog() method, and so forth. Both methods might invoke the same view, but with somewhat different data that would control what sort of message is displayed to the user, while also displaying the current user and dog stats (common to any action).
0
@NogDogJul 22.2012 — #It does not have to, but it is a common technique. Typically, you can also pass additional parameters that way, e.g "0
@NogDogJul 22.2012 — #So, your framework would initially invoke your Action controller's feedDog() method, which then itself would invoke model methods Dog::feed() and Inventory::feedDog() (or something like that). Then when all that processing is done, the controller finally would invoke your "status" view (for example).