Women in Technology

In response to Tony, I also use an abstract DataObject super class in my applications. It takes care of the basics: select, insert, update, delete. I didn't use this super class in my article, as I felt it would complicate the topic too much for the novice (although I did mention writing one in the last paragraphs). I spent some time reading over your site as well. It seems we hold many of the same views on many topics. It's nice to see someone else using XSLT for their presentation layer,

In response to EViL3, you're right, In your words: "...this is an old idea being re-hashed for a new generation." I've found that a large number of PHP coders out there (from the novice to some veterans) generally hard code queries, often repeating common DB tasks. The intention here is to get folks thinking about how best to represent data from a relational database as PHP code. Once the DataObjects are created, the coder can interact with the DB using only PHP code, not SQL. As I stated in the article, there are many ways to implement DataObjects. This article purposefully presents them in a very simplistic manner. The "how" is not as important as the "why" in this case. For a simple solution to joins, I tend to use read-only view DataObjects (I have an abstract ViewDataObject super class I regularly use).

I took some time to read about SQLMaps. And yeah, they do look interesting. Pear:DB_DataObject tries to do this (in a manner of speaking), but they chose not to use XML... an odd descision if you ask me.

Thanks for the comments.