Daevid Vincent wrote: >> -----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)... > The way I normally do it I learned from the CakePHP framework which is very similar to (I think an attempt at a clone of) Rails. I'm not sure if they do it the same way in Rails, but as you were mentioning, in a Cake view of a form they use the table name as the array name (name="Users[username]"). Internally to the framework this may make things easier, but imagine you have a page with 2 or more forms that update different tables, or if your form had some fields that you wanted to check after submission but are not DB fields. Why would you use the entire POST array? -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
