[dev] PEAR::DataObject
Chuck Hagenbuch
chuck@horde.org
Fri, 19 Jul 2002 22:00:45 -0400
Quoting Jason Hines <jch@eyeintegrated.com>:
> Well, neat things could be done if all data was abstracted into
> objects. Doing things like centralized administration for all Horde
> application in one admin panel would be possible.
Hmm. We _do_ abstract pretty much everything behind objects, but don't
always map them directly to tables - managing complex table relationships
using entity objects can bet pretty ugly.
Also, we simply don't assume that people will be using SQL for everything.
> Another good thing would be that Horde application developers would only
> have to define their DataObject configuration, and Horde could be
> responsible for the table creation, etc.
Having some automated table creation would be nice, I guess, but it's more
overhead, and not especially fun code to manage it nicely for all databases.
> The Binarycloud framework abstracts all data through the use of
> Entities. It's very nice.
I don't find this terribly convincing; I've looked at BinaryCloud in the
past, and it is almost the complete opposite of Horde in how it mandates
_everything_ and is in control of _everything_. There are of course some
advantages to doing it that way - things are much simpler if you just
_assume_ that every one of your users will have an RDBMS, etc. - but it's
not necessarily better, or where we should go.
> I was just considering the fact that Horde extensively uses PEAR and
> PEAR::DB, so I would imagine extending on that to utilize
> PEAR::DataObject would be a good thing.
I'm open to being convinced that this is so, but getting specific - show me
a piece of rewritten code that benefits from it or provides more features,
show me that it's faster, etc. - would go a long way.
-chuck
--
Charles Hagenbuch, <chuck@horde.org>
"After a few minutes the most aromatic and nice smelling Italian coffee
will come out of the exhaustpipe." - Our stove-top espresso pot