MVC confusion passing data from view to model via controller

If a view is served from a controller is it ok to pass data generated in that view via post and pass it straight to a model or do I need go back t开发者_JAVA技巧hrough the controller that served the view and call the model from the controller?

In CodeIgniter views get their data from the controller, which demultiplexes / validates parameters and retrieves the appropriate data from the model(s). It's important that:

1. Views are output. Views are not coupled with the models directly, as they define the HTML/XML/JSON/CSS (either pages, logical parts of pages, or other fragments of output data like APIs and resources). This means you do not call models from views in CI.

2. Controllers are proxies. Controllers and models do not produce output. Controllers take the GET and POST requests and make the calls needed for a view to print the result, often checking the parameters and multiplexing multiple model calls to get all of the appropriate data.

3. Models get and put data. Models should return their data in an agnostic format: either as data objects of the model, or as more generic (but consistent) hashes of data. The cleaner the returned model data, the less coupling you will find between your views and models (and the more you will be able to reuse model pieces).

In CodeIgniter there are a few places where you may find overlap:

• JavaScript often ends up related to views (and may do things like validation, normally a controller task). You can improve this by moving Javascript out of the views (works well for larger pieces, less well for smaller bits).
• In PHP, returning hashes (key/value arrays) is easier than returning objects (less code, but reduced type safety). This is often a source of coupling.
• Shared output stuff often finds its way into controllers (you can avoid this by moving it into CI helper libraries).

The goal is for your views to be unaware of your models, except that they receive data from them that meets a particular specification. Controllers just get and put (they neither generate HTML output, nor access the data directly), and models are mostly SQL or other forms of getting data and stuffing it into something structured.

Speaking in an MVC agnostic approach I would say that the View going back to the Model is the correct approach. Purist may state always going back to the Controller.

A comment from here...

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

The phrases "usually" are key. Patterns are for manageability and maintainability downstream to some degree. Sometimes patterns are a hindrance to accomplishing the goal in a maintainable and manageable manner and are sometimes overused.

I would gather that going either route would be fine in this instance (small scale)...but it is also about how you are approaching the problem on an application wide scale.

Yes, you submit form data to controller functions. That function then processes the data and calls a view.

If you try it any other way, you'll end up in code hell.

One function can handle the original display of the form and the submission of that form.

Simply check if the form has been submitted, if so, process it's data, else display the form.

function login(){

  if($this->input->post('submitted')==1){

    //process the form data

  }else{

    //show the form

  }

}