Good practice

[eluser]moodh[/eluser]
[quote author="shadow player" date="1310398082"]

can you post a link to that thread? I’d be interesting in reading their reasons for that

http://chat.stackoverflow.com/transcript...893#985893

Lets say you want to validate user input but not admin input, through the same model?

Admin input has to be validated too. Stuff admins can input and users can't (i.e. HTML in a post) are commonly set on a permission level.
If an admin accesses a common routine in a model (i.e. creating an user) that would 'normally' be accessed on user registration - he still has to enter a valid email address for the user.[/quote]

What if there's different rule sets for admins and users? Should you create a massive model instead of 2 thin controllers? That just seems well.. Weird.

Models should have a clean interface towards the database. What if you build a script to use a model that really doesn't need any validation? Then you'd have tons of validation in the way. Validation is only needed for user input, there's nothing saying your models wont be used by the system itself in various situations.

[eluser]shadow player[/eluser]

What if there’s different rule sets for admins and users? Should you create a massive model instead of 2 thin controllers? That just seems well.. Weird.

I don't think I completely understand what you mean. could you provide an example please?

Data validation has nothing to do with permission levels, the validation of an email address for instance will be equally compulsory for an admin or user.

Regardless of that fact, in an environment with different input rule sets, these rule sets shouldn't be hard-coded, rather be saved in a persistent storage mechanism like a database or configuration file. So the controller or modem doing the validation can use the corresponding rules when dealing with input.

[eluser]jmadsen[/eluser]
I think we are talking about two different types of validation here:

1) business rules - permissions, what constitutes a valid email, you must be in a group to post to it, etc

2) database rules - things you would use constraints for, relationships between tables, etc.

generally, #1 ought to go in controller, #2 in model

if you need a sitewide rule applied, such as checking permissions to update/insert, then perhaps a connection wrapper from a helper

[eluser]nuwanda[/eluser]
An aside.

This is interesting:

Model stores data into database returns positive to controller

I look at a lot of code, especially in tutorials, and it's surprising how often data is passed to a model but the model does not return a success or fail to the controller.

The controller always needs to know if the model did its job, and if not, inform the user, or do something else. Granted, it's a laborious process, but essential.

Anyone else notice this?

[eluser]nuwanda[/eluser]
BTW, I've got into the habit of validating in the controller, then if the data is good, pass it to the model.

Code:

public function process_form(){
  
    //form submitted
    if($this->input->post('submitted') == 1){
    
      if($this->validate_form()){
      
      //call model

    }
      
    $this->load->view('form');
  
  }

validate_form is also in the controller.

[eluser]StefanAlexandru[/eluser]
Ok guys as I am new to CI I have also a basic question concerning "good practice".

So where is better to have the post data in the model or in the controller :

Code:

function editcat()
    {
        $data = array(
            'name' => $this->input->post('name'),
            'catdescription' => $this->input->post('catdescription'),
            'catkeywords' => $this->input->post('catkeywords')    
        );
        
        $this->Catm->update_cat($data);
    }

I can have

Code:

$this->input->post

in the controller or in the model.. how it will be the best practice ?
Thanks in advance and sorry for my poor english

[eluser]nuwanda[/eluser]
Your post data will be in your controller since that's where it's been sent from your view.

As mentioned above, I validate my post data in the controller and then send it to the model for database updating/insertion. But you could send it all to your model for processing and then return a result to the controller.

[eluser]lefoup[/eluser]
[quote author="jmadsen" date="1310266524"]I would say validation is business rules, and should be left in the controller.

The model should only be concerned with database integrity.[/quote]

I would definitely agree with that, best practice in my opinion!

[eluser]moodh[/eluser]
[quote author="shadow player" date="1310432633"]

What if there’s different rule sets for admins and users? Should you create a massive model instead of 2 thin controllers? That just seems well.. Weird.

I don't think I completely understand what you mean. could you provide an example please?

Data validation has nothing to do with permission levels, the validation of an email address for instance will be equally compulsory for an admin or user.

Regardless of that fact, in an environment with different input rule sets, these rule sets shouldn't be hard-coded, rather be saved in a persistent storage mechanism like a database or configuration file. So the controller or modem doing the validation can use the corresponding rules when dealing with input.[/quote]

So if you get 100% validated data from another part of your system, lets say an auto import or maintenance systems, should it get validated again because the validation logic is in the model? That seems redundant.

[eluser]icomefromthenet[/eluser]
The majority of codeigniter controllers can be classified as Transaction Scripts. With very thin models that handle basic CRUD operations.

This is fine for small projects, blogs and simple content managment system.

When the complexity of the project rises, you really need to create a proper domain model.

Tools like DataMappers, ActiveRecord ORM's help you quickly develop the basic CRUD in your domain, up to you to add the business logic, and access rules.

The Codeigniter database class is only a query builder and will not do for complex projects.