? - The new DB_DataObject_Cast was designed to do this for 'writing'
DB_DataObject_Cast::blob()
DB_DataObject_Cast::date()
DB_DataObject_Cast::sql()
... they're not in the current package (or at least not standing-out in the documentation), so I can't say one way or another if they do the trick for me. I look forward to their inclusion or documentation the next time around.
As usual it's in CVS, I was waiting on some feedback to make sure the other changes that are in CVS are working OK (which seems to be the case)
The top of this gives a few usage examples..
http://cvs.php.net/annotate.php/pear/DB_DataObject/DataObject/Cast.php?rev=1.5
Although real docs are still a way off.. (even DB_DataObject::factory() is not even documented yet, and it's one of the key new features of the 1.0 series)
Yes, if DataObject supported more "common" types (such as DATE, TIME, etc) that'd be cool. But so far as I have seen, it does not do so in the most recent packaged release; only INT and STR are there, unless I am missing something.
There was always code to support it, just not implemented :) - there have been defines for a number of types in there forever.
Yes, although I have to say the mapping .ini files are not very intuitive. More power == more complexity, of course, and DB_DataObjects is more powerful than DB_Simple in many ways.
It may seem kludgy but it's result of a trade off of speed against flexibility.. - in this case ini files are flexible enough, and dam fast :)
<not a flame>
The following is _not_ a flame against the DB_DataObject and MDB authors.
I played with both MDB and DB_DataObject for about 20 hours each, and found the documentation and examples somewhat lacking.
You know what's the response to that :) - If the documentation is 'lacking' suggest improvements or write a short note for it.. (actually we still desperatly need 'manual notes'.)
The .ini file
format for DB_DataObject is not that well explained, It is mentioned (both on the required configuration options and createTables docs), though not in much detail, as I guess that as it's autogenerated, it's not normally neccessary for users to know too much about it (other than it exists..)
Code authors have better things to do than explain our methods and procedures to newbies, but to aid developers in the use a package we need to do just that (i.e., write our docs "for Dummies" and "for people who have no time" and "for all sorts of possible cases"). If MDB and DB_DataObjects had better docs,
http://pear.php.net/manual/en/package.database.db-dataobject.php
I'm not sure, but I would (blowing my own trumpet) say that DataObjects, docs are some of the best in PEAR... - but I would welcome ideas for improvement... :)
I
That is why I propose DB_Simple: it's easy to get started with, it's well-documented internally, and if it is accepted I will deliver additional high-quality external documentation. [1] Those of you who have seen the Contact_Vcard_* docs know that I am as good as my word when it comes to extensive instructions, explanation, and examples.
The trouble you get into with this, is that if you start with a simplified version trying to merge features of other packages that already exist.. eventually users start asking.. 'can you add this.....' etc. and it grows.. Effectively what you have today is what DataObjects was about 3 years ago..... (+/- some minor features..)
As far as adding to the DB_DataObject code base: if DB_Simple is not
accepted, I'd be happy to commit the extra functions as DB_DataObject proceeds toward the end of its todo list. However, I don't think anything I have will be useful until DB_DataObject supports those other datatypes.
I would die for more help on DataObjects, I still have a couple of patches/ideas in my Inbox that need sorting out :)
Regards
Alan
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com