Ideas for improving the emoncms framework

2) Straight mysqli instead of db.php abstraction

While rewriting the core framework from scratch it hit me that the db.php abstraction I created that converts mysqli class calls into global scope db_query etc functions is not really that useful and probably just confusing. db.php never did anything useful on top of mysqli like input sanitisation or anything like that so I think it would just be better to write straight mysqli.

Which leads on to the next point:

3) Models as classes

After using the mysqli class with the $mysqli->query() $class->method() type interface I started to experiment with using php classes for the emoncms models instead of just a file full of functions. Here's an example for the feed class with only one method for loading a users feed list (notice also how $mysqli is passed into the class for use)

class Feed
{
  private $mysqli;

  public function __construct($mysqli)
  {
    $this->mysqli = $mysqli;
  }

  public function list($userid)
  {
    $feeds = array();
    $result = $this->mysqli->query("SELECT * FROM feeds WHERE `userid` = '$userid');
    while ($row = $result->fetch_object()) $feeds[] = $row;
    return $feeds;
  }

}

To use this in the application we first create an instance of the class

$feed = new Feed($mysqli);

and then call the methods needed:

$result = $feed->list($userid);

This gives us a nice interface to the feed model in the rest of the application, it's a clearer naming convention model_name->method_name() and its clearer that model methods and properties belong to that model. There are also a whole load of other potential benefits as time goes on such as extending the class and so on (all standard stuff in most frameworks)

4) The fat model and thin controller

In reading more on the model view controller pattern I came across this article which really made a lot of sense to me: http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/

The question of what should be in the controller and what should be in the model is something that I had been a bit unsure about and so far I have usually put input validation and any error reporting in the controller while trying to confine the model to primarily data access. 

But looking again at this and with the clarity of that article, it makes sense to me that input validation and error reporting should be in the model instead.

When coupled with the class based model that model then becomes a very complete and portable class that can be used in different applications or frameworks as the article suggests with all the validation and error reporting intact.

The controller's role then becomes: translation of the external http api to model method calls , fetching of input via $_GET and $_POST and passing these to the model method parameters and checking to see if the user has the correct privileges to call the model method.

5) php code formatting standards