Re: [PROPOSAL] DB_Simple

Hi, Alan, With regard to these...

DB_DataObject is only moderately complex, but does not appear to support automated table creation,

- This has been on the TODO for a while - I Believe people have already hacked the Generator to do this already.

definition of calculated columns, or

- To some limited degree it does.. there are defines at the top which do this.

abstracted data types.

? - 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.

To fill in the spaces between these three, DB_Simple provides: <snip> things that are pretty similar to DB_DataObjects</snip>

- automated validation of insert/update data on a by-column basis

This is quite nice.. - Although DB_Dataobjects has a simplistic hooks for validation (I dont tend to use them, much prefering UI validation normally).. It would be quite logical to seperate this out to DB_DataObject_Validate::validate($dataobject);

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.

- clean-running (no notices under E_ALL) and well-commented code

     compatible with both PHP4 and PHP5

That I have to sort out :) - those PHP5 buggers who broke __call() :)

Yeah, me too -- I should have said it _should_ be compatible with PHP5. I'm just doing the monkey-see-monkey-do thing right now (I see other PHP4+PHP5 code, I try to code along with it).

DB_Simple is _not_: - a data object per se; instead, it acts as an interface to a single

     table for insert/update/delete (although the automated SQL maps may
     select from joined tables as desired)

In theory DB_DataObjects can be used like that.. - and the plan is to move to this concept where some 'dataobject sub classess' arent always needed.

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.

- a replacement for MDB or DB_DataObject, although it walks a

     parallel path.

In general, It has a huge overlap with DataObjects, almost all of the ideas are already in the TODO list for dataobjects. (either the planned MDB version or the current 'classic')..

Yes, it has a great deal of overlap with both DB_DataObjects and with MDB. I fear it is unavoidable; until both of those packages are more thoroughly and more formally documented by their authors, with example cases, it might be easier for new users to grasp a more simple approach to data abstraction and query automation. <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. The .ini file format for DB_DataObject is not that well explained, and MDB is just convoluted internally (unavoidable in the case of MDB, since it wraps together code from two otherwise unrelated projects). In short, MBD and DB_DataObject are difficult to get started with. That's not a sign of bad code, but it does provide an opportunity for better package stewardship when it comes to helping out users who are new to the package. 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, I might be able to use their power more effectively, but as it stands there is a rather tall barrier to entry there. Again, the above is _not_ a flame -- it's good code, it's just difficult and time-consuming to figure out. </not a flame> 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. If nothing else, perhaps we can see DB_Simple as a baby-step for coders who will then progress to DB_DataObject and MDB proper.

It's a great presentation of the class though

You're very kind to say so; thank you.

(although it's usually better to post links to phps's rather than attaching the file..)

Yeah, sorry about that. Will do so in the future. Sorry to violate protocol.

I know it's a pain - having completed the current code, but I would seriously suggest thinking if it could be added as a utility class to DataObjects (validation), or add extra functionality to dataobjects (autocalling the generator..., extending the generators type knowlege...)

I'm going to use DB_Simple myself, even if nobody else does (have in fact been using previous versions of it for over a year). It's no pain to me if it's not accepted, because I didn't write it "for PEAR" (although I like to maintain PEAR compliance in all my own code). I just thought that if it's useful to me, it would be useful to others (thus the proposal). Kind of like my original proposal for HTML_Template_Dummy (which has turned into Savant, see the signature block ;-). 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. Thanks for the critique, Alan, I hope we can agree on at least some of these points. :-) -- [1] My own opinion is that code is not ready-for-sharing until it is thoroughly documented internally in the JavaDoc style with along-the-way explanations, and that a package is not ready-for-release until it has thorough external documentation. But that's just me. _______________________________________________________________________ Paul M. Jones Savant: the simple alternative to Smarty. http://phpsavant.com/