Where should my code go?
This article helps you understand where you should place new code within the model-view-controller design pattern.
When I started developing my first CakePHP application, I was flustered every time I want to add new code. I didn't know where it "belonged" within the existing framework and conventions. As I found answers to my questions, I started this list.
Before reading this, make sure you understand the model-view-controller design pattern.
The "take away" message for each part is highlighted in bold.
Before reading this, make sure you understand the model-view-controller design pattern.
The "take away" message for each part is highlighted in bold.
Models
- Models are designed to hold and manipulate data
- Models essentially reflect a database table
- Models (usually) never represent a row in a table, just the table itself
- Models have functions that deal with manipulating data from the table
- Models should be large and should contain the majority of the logic for your application--(remember: fat models, skinny controllers)
- Anytime you are doing the same thing to a model in multiple places, you should refactor that functionality into a method within the model (instead of having it in multiple places outside the model).
- Cookbook: Understanding Models
Behaviors
- Behaviors allow you to add the same functionality to multiple models
- Examples: tree, soft deletable, increment.
- Cookbook: Behaviors
Controllers
- Controllers are designed to separate your site into sections
- Examples: BlogController, SearchController, GroupsController, UserProfileController
- Contrary to what the blog tutorial makes you think, there is not a single controller for every model (or a single model for every controller). It is fairly common that a controller will hold all the tasks of a single model, but it is NOT necessary for things to be that way.
- On the same token, avoid mixing controller uses. While there may not be a controller for every model, don't put actions that deal with model B into model A just to avoid having to create a controller
- Controllers should be small and NOT contain the majority of the logic for your application--(remember: fat models, skinny controllers)
- The controller isn't there do do everything. It is there to determine what needs to be done, and have other people do it
- Controller actions get data ready to be presented in a view
- Cookbook: Introduction to Controllers
Components
- Components have logic that is shared across multiple controllers
- Remember, logic should only be in multiple controllers in the first place if it is getting data ready for the view. If the logic is just manipulating your data, it should be in a model.
- Cookbook: Introduction to Components
Views
- Views are individual pages within your site
- Views are the user interface to your program
- Each view has a function inside the controller with a matching name. These functions are called actions. Each action gets the data ready for a specific view.
- Views present data
- Views allow you to separate your user interface from the rest of your application
- Cookbook: Introduction to Views
Helpers
- Just like the name says, there are helper functions that make rending things in views more convenient.
- Cookbook: Intoduction to Helpers
Elements
- Sections of code that will be used in multiple views
- Cookbook: Elements
Comments
Comment
1 In my opinion...
* Models (usually) never represent a row in a table, just the table itself
- sorry, but, based in what have you came to this conclusion? As far as I know, models - here understood as every subclass of the Model class - have the $id property exactly to deal with that, and there are lots of actions where your model will only represent a single row, actually, one could say that: Models usually represent a row in a table, except when you are paginating, building reports, filling graphs... , or could have just thrown this item away - which is much better in my opinion.
* Controllers should be small and NOT contain the majority of the logic for your application--(remember: fat models, skinny controllers)
- I don't think that the concept of "fat models, skinny controllers" applies to this one. "Skinny controllers" only mean you shouldn't handle data inside the controller. or at least as minimum as possible, but the controller still is a "Controller" which means that it "controls" the application state and actions, so, yeah, one can put a lot of logic down there.
* Components have logic that is shared across multiple controllers
- Well, not that it's not true, but it's kind of incomplete, Components are far more useful than that, they can be the interface for external sources/servers/actions - access smtp servers, ping, send, post... - and can be wrappers for external libraries.
Comment
2 Plugins ... ?
Comment
3 re: Plugins ... ?
Technically you could put any full application as a plugin. So for example you write a full forum, and that could become a plugin that you drop in to projects you want to use it on and just use. Mostly it's meant for open projects with a separate respository (like cakeforge).
Question
4 Examples?
Question
5 What about "extra" controller functions?
I note that declaring a function "private" solves this issue, but is this the way it's "supposed" to be done?
Comment
6 What do i do?
what do i do if i need to add a picture to my main page and add link to that picture?
Also tell me how do I add forms to my main page?