monomelodies/ornament

PHP5 ORM toolkit

Ornament

PHP5 ORM toolkit, _(*1)

ORM is a fickle beast. Many libraries (e.g. Propel, Doctrine, Eloquent etc) assume your database should correspond to your models. This is simply not the case; models contain business logic and may, may not or may in part refer to database tables, NoSQL databases, flat files, an external API or whatever. The point is: the models shouldn't care, and there should be no "conventional" mapping through their names. (A common example would be a model of pages in multiple languages, where the data might be stored in a page table and a page_i18n table for the language-specific data.), _(*2)

Also, the use of extensive and/or complicated config files sucks. (XML? This is 2015, people!), _(*3)

Installation

Composer (recommended)

Add "monomelodies/ornament" to your composer.json requirements:, _(*4)

$ composer require monomelodies/ornament

Manual installation

1. Get the code;
   1. Clone the repository, e.g. from GitHub;
   2. Download the ZIP (e.g. from Github) and extract.
2. Make your project recognize Ornament:
   1. Register /path/to/ornament/src for the namespace Ornament\\ in your PSR-4 autoloader (recommended);
   2. Alternatively, manually include the files you need.

Basic usage

Ornament models (or "entities" if you're used to Doctrine-speak) are really nothing more than vanilla PHP classes; there is no need to extend any base object of sorts (since you might want to do that in your own framework!)., _(*5)

Ornament is a toolkit, so it supplies a number of Traits one can use to extend your models' behaviour beyond the ordinary., _(*6)

The most basic implementation would look as follows:, _(*7)

<?php

use Ornament\Model;
use Ornament\Adapter\Pdo;

class MyModel
{
    use Model;

    // Public properties on a Model are considered "handleable" by Ornament:
    public $id;
    public $name;
    public $value;

    public function __construct()
    {
        $this->addAdapter(new Pdo($GLOBALS['database']));
    }
}