I am also very interested in the topic. I have tackled the query building part a bit with the recent LiveUser_Admin rewrite. We now generate the queries on the fly. Basically the user specifies the fields he wants to fetch, the filters (as in the where conditions), ordering etc and LiveUser_Admin_Storage determines the necessary joins automatically.
There are some limitations in that currently all that is allowed are AND'ed statements without any parenthesis. It also doesnt handle stuff like GROUP BY and HAVING yet. This was mainly done in order to give us a realistic shot at implementing an XML based storage container.
Also we are not using objects for all of the entities, but this is not really a requirement obviously and can easily adapted.
Here are the relevant links:
We havent done much in detail analysis about the performance yet though, but its been working quite nicely for us.
Just as a showoff:
The following query is generated from this API call:
$params_groups = array(
'fields' => array('group_id', 'right_id', 'name'),
'filters' => array('perm_user_id' => '1')
Also note that the implementation of getGroups() basically requires only a list of tables that should be included in the join of needed. The table from which the joins are to be made (in this case the liveuser_groups table) and then a single call to actually generate and execute the query.
SELECT liveuser_groups.group_id AS group_id, liveuser_grouprights.right_id AS right_id, liveuser_translations.name AS name
FROM liveuser_groups, liveuser_groupusers, liveuser_grouprights, liveuser_translations
WHERE liveuser_groupusers.perm_user_id = 1
AND liveuser_groups.group_id = liveuser_grouprights.group_id
AND liveuser_grouprights.right_id = liveuser_rights.right_id
AND liveuser_rights.right_id = liveuser_translations.section_id
AND liveuser_translations.section_type = 4
Anyways .. just wanted to provide this as some food for thought. Like I said I am interested in the project and I am not trying to offer LiveUser_Admin_Storage as the solution. :-)
function getGroups($params = array())
$selectable_tables = $this->selectable_tables['getGroups'];
$root_table = reset($selectable_tables);
return $this->_makeGet($params, $root_table, $selectable_tables);
As for the choice of PHP4 and PHP5. To me PHP5 is not really more advanced in terms of OO. The two real advantages boil down to more reliable interceptors (__get(), __set(), __call()) and not having to pass objects by references anymore. The other stuff is (useful) syntax sugar. One of the more useful syntax sugar additions are no doubt interfaces. These could proof to be a very useful addition to this project.
However I think it would be wise to attempt to write this thing in PHP4, making specific notes about things where we actually get hurt by a PHP4 limitation and then making a final decision later. For example interceptor support my in the end just make the API more convinient for users by making it possible to shorten API calls and lazy loading certain things. But shutting out PHP4 users when its not necessary is obviously worse than having a less convinient solution in PHP4 as long as it doesnt significantly diminish the usefulness in PHP5.