Here's my review of Outlet ORM. I have it working and I _love_ it. It's the simplest ORM tool out there that I've seen, is lean, and runs fast. How could we not notice this?
1. I couldn't get your Outlet::init() function to work unless I fed it:
include('outlet-config.php')
..as in:
Outlet::init(include('outlet-config.php'));
2. The 'docroot' thing from the Quick Start Guide was confusing to me. My directory structure was:
/var/www/myapp/lib/outlet <-- your outlet class files, stuck under lib so that I can stick other libraries there too, such as Smarty and whatever
/var/www/myapp/orm <-- my Member and Address classes (my custom ORM)
/var/www/myapp <-- my index.php page and 'outlet-config.php' page is here
So, I reach it with
http://127.0.0.1/myapp/
However, I had to change your init code like so:
define('APPROOT', dirname(__FILE__).'/');
set_include_path(APPROOT.'/lib/outlet:' . get_include_path());
require_once('Outlet.php');
require_once('orm/Member.php');
require_once('orm/Address.php');
Outlet::init(include('outlet-config.php'));
$outlet = Outlet::getInstance();
$outlet->createProxies();
3. I had to install docbook-utils and then run docbook2pdf on your outlet.docbook file to generate a PDF to read the additional documentation.
4. I had to add a 'dialect' of 'mysql' to my outlet-config.php file beneath the dsn parameter:
'dialect' => 'mysql',
5. Do you have a 'todo' list for this project so that I can learn what doesn't work yet, or that you might be changing/improving soon?
6. If you have an entity class that ends in -s already, it creates an odd situation where it doesn't use -es instead as the suffix, requiring me to have a couple odd class methods in my Address class that looked like:
public function getAddresss() { //misspelled due to odd thing about Outlet
return $this->_Addresses;
}
public function setAddresss(array $Addresses) { // misspelled due to odd thing about Outlet
$this->_Addresses = $Addresses;
}
7. Perhaps you could consider an alternate way of doing the outlet-config.php file, such as allowing me to do it .conf style like so:
connection.dsn = blah blah
connection.user = blah blah
connection.password = blah blah
classes.Member.table = members
classes.Member.props.ID = id, int, pk:true, autoIncrement:true
...and so on
8. In my index.php test, I still had to require my Member and Address entities that I needed:
require_once('orm/Member.php');
require_once('orm/Address.php');
...but the docs didn't mention that.
9. It might help to create a Bash script that one runs at command line. It could ask for the database name, username, and password. It would build an outlet-config.php file automatically. It could infer foreign key relationships, but on all associations it would clearly state that this was a TODO area for the programmer and that it made a best guess based on field names.
For instance, if I have 'members' and 'addresses', and if 'addresses' contains 'member_id' or 'memberid', then you can be pretty certain that I have a foreign key association there in addresses, referencing back to members. The script could automatically detect this and try to build that in the outlet-config.php file automatically.
10. You state that when building outlet-config.php, you have varchars and ints. Although I completely understand what you're doing here and don't have a problem with it -- you may have newbie programmers who want to use 'date' or 'timestamp' rather than 'varchar', so your documentation may need to reflect why it's only 'varchar' and 'int', and which one they should use for certain datatypes.