121
Yes m8,
Thanks, and my apologies for the lack of answer (but we're quite busy at the mo and aren't answering to all posts even if we're reading them
).
Actually, I've already done something like this some time ago except that the additional data (id fieldname, table name...) was passed using additional constructor parameters and the queries autogenerated looping through the XoopsObject vars.
Extremely simplified, it looks like this:
But this hasn't been sent to the actual kernel as Kazu is experimenting a solution that would be more optimised (a bit like yours, except that all the data access code would be generated by the XOOPS kernel during module installation / object types registration, so modules writers don't even have to write the methods by themselves).
Also, there are some problems in the actual XoopsObject interface (i.e: the default format for getVar() should be 'n', etc...) and we're actually wondering if this wouldn't be best to offer a new / enhanced class instead of building on the actual XO layer.
But thanks again. I believe we'll be really back soon, and ideas like this are always welcome. So stay around, you may have others ones we hadn't already.
Skalpa.>
Thanks, and my apologies for the lack of answer (but we're quite busy at the mo and aren't answering to all posts even if we're reading them
).Actually, I've already done something like this some time ago except that the additional data (id fieldname, table name...) was passed using additional constructor parameters and the queries autogenerated looping through the XoopsObject vars.
Extremely simplified, it looks like this:
function &get( $id ) {
$tgt =& $this->create();
$vars = implode( ",", array_keys( $tgt->vars ) );
$query = "SELECT $vars FROM {$this->table} WHERE {$this->idfield}=$id";
......
}
But this hasn't been sent to the actual kernel as Kazu is experimenting a solution that would be more optimised (a bit like yours, except that all the data access code would be generated by the XOOPS kernel during module installation / object types registration, so modules writers don't even have to write the methods by themselves).
Also, there are some problems in the actual XoopsObject interface (i.e: the default format for getVar() should be 'n', etc...) and we're actually wondering if this wouldn't be best to offer a new / enhanced class instead of building on the actual XO layer.
But thanks again. I believe we'll be really back soon, and ideas like this are always welcome. So stay around, you may have others ones we hadn't already
.Skalpa.>
.
