Few questions about MVC stuff

[eluser]jhyland[/eluser]
So im just learning both OOP and MVC as well. However, CI makes it very easy to take on OOP,

Im working on a rough draft of a new application, and im running into a few logic errors relating to MVC...

1) I get that data related stuff goes into the Model, and the logic goes into the Controller, and any HTML output related code goes into the View, but where do I put the code that validates/sanitizes and runs logic to user input for the SQL query within the model? Does that go inside the model? If a step in my input validation/logic fails, how does that get handed from the model to the view?

2) Heres an example of a good chunk of PHP that im using, its just a switch statement, but right now, its in a view. A different view will grab the sql data from a model, then for each row thats returned, it includes the view that has all of this PHP (So its a nested view). My question is... is this too much PHP for a view? If so, how do I fit it into the controller? http://pastebin.com/5Dj4Z7ze

3) Ive looked around, and I see a lot of tutorials about how to write insert statements for mysql, but say for example.. I want to test if the update failed. How do I execute it in the model, then hand the return code back to the view for checking? (Or should it be the controller that checks?...)

I think thats all the questions I have right now, ill update if I have more.

[eluser]WanWizard[/eluser]
1. I do all validation in the model. The advantage is that no matter where in your application you manipulate the data, you are sure that what is stored is correct. You also don't have to copy the validation code to every controller that needs it. Keep you code DRY (don't repeat yourself).

I use exceptions to handle error situations. In your controller, call the model in a try/catch block to catch the exceptions.

2. A view should not contain logic. It may contain PHP for display purposes (like generating rows from an array in a loop) or simple if statements, but definately not more. Ideally the model should hand the data back to the controller in the format that is required, keep the post-processing to a minumum.

Not sure what you mean by 3. Are you talking about a CRUD operation (an entry form that inserts or updates a record)?

[eluser]Aken[/eluser]
I do form validation in the controller, and checks / sanitization in the model. In my experience, I've rarely needed to share form validation rules between more than one controller. If that particular controller has more than one method that shares rules (create() and edit(), for example), then I load the validation rules in the constructor or a protected method. This is something that's far more opinion than standard, although to me, the controller is designed to capture and handle input by the user, so that is the appropriate place to validate that input.

[eluser]jhyland[/eluser]
Should the code that pulls from JSON/XML api be in the model?

[eluser]Aken[/eluser]
That depends on what you mean by JSON/XML API.

[eluser]WanWizard[/eluser]
For me, yes.

It doesn't matter where the data comes from, it doesn't have to be a database. The model should be a single entry point to your data.