> -----Original Message----- > From: Shawn McKenzie [mailto:nospam@xxxxxxxxxxxxx] > Sent: Wednesday, November 04, 2009 6:20 AM > To: Allen McCabe; PHP General > Subject: Re: Custom function for inserting values into MySQL > > In your example, I would name my form inputs similar to name > ="data[user_id]". > > Then you just pass the $_POST['data'] array to your function. > > -Shawn > > Allen McCabe wrote: > > You raise some good points. I always name my input fields after the > > entity names ( eg. input type="hidden" name ="user_id" value=" ?php > > echo $resultRow['user_id'] ? " ). > > > > I suppose I am still in the phase of learning efficiency, > and perhaps > > trying to 'get out it' by writing functions that I can just call and > > pass parameters instead of fully learning the core concepts. > > > > I just think functions are so damn cool :) > > > > > > I'll echo what the others have said about the > parameters. For me > > personally, if I am passing more than three parameters > (sometimes even > > three) I rethink my function. I'm not sure what you envision > > using this > > function for, but the approach I use for forms and > databases is always > > arrays. I get an array from my forms, I insert that > array into the > > database, and of course I fetch arrays out of the > database. These are > > all indexed the same with the index as the field name > of the table so > > it's easy. > > > > > > -- > > Thanks! > > -Shawn > > http://www.spidean.com > > > > > > There are pro's and cons to this type of thing. In general that is how I do it too, but you have to be aware of security and organization. It's not always smart to expose your DB field names directly so you might want to obscure them for some critical values. If your passing from one controlled function/method to another then this isnt an issue so much. I also follow the ruby/rails ideal where tables are plural names ("users") and classes are singular names ("user.class.php"). Tables always have fields for 'id','created_on','timestamp','enabled'. Except in 'glue table' cases (1:n or n:m). Classes extend a base class which handles a lot of the minutea including the magic __get() and __set() routines as well as knowing what table they should be through introspection (ie. Their own file name). No need to name your fields as arrays. $_POST is already an array. You've just added more complexity/dimensions. When you submit your form just pass $_POST to your function instead. In the function, is where you should do any normalizing, scrubbing and unsetting (as per good MVC ideology)... In your page form: if ($_POST['submit'] == 'Update') { $result = process_data($_POST); } Then in some include file somewhere (here is a simplified example of course): function process_data($data) { //perhaps you don't care about the submit button unset($data['submit']); //maybe you don't want everyone to know your DB schema //so you re-map from form element names to DB fields... $data['user_id'] = $data['uid']; unset($data['uid']); //strip white space off foreach ($data as $k => $v) $data[$k] = trim($v); //do validity checking of each important data item if (intval($data['user_id']) < 1) return false; //any other pre-processing //do interesting stuff here with scrubbed $data array now sql_query('UPDATE mytable SET ...... WHERE user_id = '.$data['user_id'].' LIMIT 1'); //of course, I would use a routine that builds the update / insert statements from //the array key/value pairs -- see previous attached example base.class.php in this thread. } http://daevid.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
