DB_DataObject: Form Submission Best Practices

From: Date: Mon, 05 Apr 2004 06:22:01 +0000
Subject: DB_DataObject: Form Submission Best Practices
Groups: php.pear.general 
Request: Send a blank email to pear-general+get-11620@lists.php.net to get a copy of this message
There seems to be a complete lack of tutorials explaining DB_DataObject best Practices and examples, so I’m trying to open up this thread to get some feedback that may possibly solve this problem at some point. Hell, I’ll even write one, once I feel like an DO expert (Which I’m definitely not yet). Okay, so I know there is the setFrom() function which automatically sets form field values. In my code I have two tables the form uses Content and Artist. my CMS has a Content table which holds a record for almost every piece of data in the App. Artists, News Stories, System Pages, etc... This means that there is a central registry of info with some standard pieces of data that apply to every type of content. Some content has more than just name, des, lastModified, etc. Artist is one example. These types have a seperate joined table with this complimentary data. So an artist record has: name and des from Content and long_des and age from Artist. Artist has an artist_id column which links to content_id. So content_id is enumerated with auto-increment and artist_id is created manually based on the insert into Content. I know this is a bit convaluted, but it made the most sence at the time and does have many advantages... To make for seamless (lazy) processing, I’ve named all form fields in the following format: {table}-{field}. So my code loops through the post vars splits the vars , and decides: If($table == “Content”) { $fields[“Content”][$field] = $_POST[$field]; }elseif($table == “Artist”) { $fields[“Artist”][$field] = $_POST[$field]; } Now I can use setFrom to set the values in the tables and run update() or insert as needed. Weph, okay background given. Now, here are the issues: Where do you include business logic? In the DataObjects_{Table} class in set and get? What does the code flow look like? Right now I have check for an ID (update) or null ID (insert) 3 times! Currently I check for the ID at the top of the page. And if I find it I run get on it and getLinks. Then I check for submit. If found, I do the above procedure of putting form fields into their respective tables and I process them via business logic in the Data_Object classes. If there are errors in the processing, I add them to a global error handler's array via a static function from within the classes. If no errors, I then check for the ID (again) and if found, run update, else insert. Outside of the submit if stmt I check again for the ID and if found I have to create a new instance of both DataObjects so I can get the new results (after an insert or update it should be the same, but some fields have default values that may not have been on the form when it was blank). Then I create the form values from userValues (if no record exists yet) or from the newly instantiated DO classes (if it does exist). I then run any complex form creation stuff like select boxes, lists, etc. etc. and process output for the errors. Is this convoluted or what!! It's really getting to me that being lazy takes so much work and code! Being lazy is the hallmark of good OOP programming in my opinion, and this sorta defeats the purpose. But is this what everyone else is doing? Thanks for reading this LONG letter. Jacob For inserts what are you doing though? In my actual case I have two tables: Content and Artist I'm opting for just instantiating both tables and updating them independently. This is also a kludge of sorts, but since MySQL doesn't have views it seems to be the most logical solution. trying to fake it a little bit further doesn't really solve any end goal for me and requires a lot of manual putzing around. Jacob Singh Technical Director Calabashmusic.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.617 / Virus Database: 396 - Release Date: 3/9/2004

« previous php.pear.general (#11620) next »