Well, I had tried to do it some time ago, but it was not that easy...
IMO it would be easier to rewrite the whole thing from the ground up,
already with "containers" (DB, MDB, XML, LDAP...) in mind.
From the implementation of the LDAP_DataObject, it's clear that although the interface is similar (it shares only about 3 -4 methods and hence has little value sharing the same codebase (the shared methods are just simple setters for where/selectadd etc.). It also has a few key 'non-compatible issues' like all elements are arrays in LDAP, rather than simple variables...
I suspect this will be true of MDB/XML/LDAP etc. - they will have a similar API, but share very little code.. - It does make it a little more difficult to replace one driver with another.. - but since the dataObjects generator already allows you to replace extends automatically. - I'd be tempted to live with that rather than add a complex abstraction layer.
given the maintence issues I dont think maintaining 2 seperate classes would be a nightmare, otherwise, it would be quite simple to implement a simple preparser using the tokenizer to implement
#if MDB
......
#endif
#if DB
...
#endif
as a pre-packaging tool..
Regards
Alan
I tried to do such a thing with QueryTool, but a "container" schema
would need too many "redirected" methods, since this tools are supposed
to work directly with databases, and not only using them for storage purposes
like in PEAR::Cache or Mail_Queue.
I hope a simple example will be clearer:
==============================================
myBaseClass
{
var $container; // db container. May be a DB or MDB object
// my common methods
function getAll()
{
// all methods should point to the container's specific ones:
return $this->container->getAll();
}
}
myBaseClass_Container
{
// abstract class
}
class myBaseClass_Container_mdb extends myBaseClass_Container
{
//...
function getAll()
{
//...
}
}
==============================================
See what I mean? Of course this is just one way to do it, but PHP4
can't (the way I see it) handle this situation in a more elegant way,
while it would be easier in a language like Java (or PHP5?).
If you have other suggestions or design ideas, please share them,
because I'm very interested too...
Regards,
Lorenzo