Correct way to return from model to controller
I am sorry for this question, but I am really disappointed with this situation.
This is my controller
public function changeName_PUT() {
header('Content-Type: application/json');
$return = \Models\User::getCurrent()->changeName(Input::data());
return json_encode($return);
}
And this is my model
public function changeName($data){
$rules = array( ... );
$messages = array( ... );
$valid = Input::validate($data, $rules, $messages);
if($valid === true){
return $this->putIntoDb(array('name' => $data['name'])) ? 'Namechanged successfully.' : 'An error occurred.';
}else{
return $valid->getMessage();
}
}
My problem is that no matter if the model succeeds or fails, a string is always returned, so in the controller I cannot tell if the name has been changed or not. If I return only true
or false
, then in the controller, if something doesn't work, I don't know what it was. My other option is to return arrays from the type model array('error', 'message')
, but that looks so ugly and gives me the feeling that I am doing it wrong. Can you point me to the right path?
source to share
You have different approaches:
-
Simple version: if you are inserting, return insert_id | false. If you remove, return true | false. If you update return true | false. If you choose, return an array | string | false.
-
Class version: you return true or false (except select which returns a queried string array |). And you store the error messages in a class variable so you can do something like:
$success = $model->query('blabla'); if (!$success) print_r($model->getMessages());
-
Object version: Same as the plain version, except that you return the database object on a successful select or update request (false otherwise).
-
Exceptional version: Same as the object version, but instead of returning false, you are throwing an error describing the problem.
Now if you look at the general framework, you can see that CodeIgniter uses the object version, Phalcon uses the class version, Zend uses the exception version. There is no "best way", just use the method and stick to it for all your models.
(just don't return a string explaining the failed request error!)
source to share
The model layer shouldn't send data to the controllers at all.
In the MVC architectural pattern, controllers are responsible for changing the state of the model layer. And so it is. Browse through the instances, then pull the required information from the mentioned model layer.
If an error condition is triggered due to changes in the controller at the model level, then the controller doesn't care about that. This is only relevant for the view, which, based on whether an error has occurred, can choose a different set of templates to build the response.
PS: HTTP headers are part of the response. So why are your "controllers" generating a response? This is basically the same as echo placement .
source to share