While I would avoid using $this->input->post() in my models where possible, validation rules are largely determined by the structure of your database, so there are only a small number of reasons that any validation rules should reside in the controller.
Because the form_validation library makes it simple to perform validation and make the results of that validation available to the view, I usually load the library from my controller and run the validation there, but I store the rules in my model and only allow the controller to define validation rules which are specific to the controller's action. Bonfire does have a method in its base model which allows you to validate insert and update calls within the model, I just usually prefer to setup the extra steps in my controller in case I need some controller-specific validation.
I also use a prep_data() method in my model (also supported in the Bonfire base model) which accepts an array (the controller calls $this->input->post() and may or may not modify the data before passing it to the model's method) and allows me to ensure default values and other requirements are fulfilled as well as ignoring/removing data which is not related to the model.
For example:
PHP Code:
class Ticket extends Admin_Controller
{
// ...
private function saveTicket($type = 'insert', $id = 0)
{
// Optionally, the result of get_validation_rules() can be
// assigned to a variable and modified before being passed to
// set_rules().
$this->form_validation->set_rules($this->tickets_model->get_validation_rules());
if ($this->form_validation->run() === false) {
return false;
}
// Optionally, the result of $this->input->post() can be
// assigned to a variable and modified before being passed to
// prep_data().
$data = $this->tickets_model->prep_data($this->input->post());
if ($type == 'insert') {
$id = $this->tickets_model->insert($data);
if (is_numeric($id)) {
return $id;
}
} elseif ($type == 'update') {
$ticketKey = $this->tickets_model->get_key();
$data[$ticketKey] = $id;
return $this->tickets_model->update($id, $data);
}
return false;
}
// ...
}
Some developers can find this kind of back-and-forth between the controller and model during handling of view data awkward, but it is primarily intended to make it easier to maintain the site in the long-term and allows the same level of flexibility while ensuring that maintainability. In many cases, I've seen situations in which developers were expected to use and understand frameworks with greater levels of separation and abstraction than this.
