one generic class or module to store data in database

[thepreacher]

Hello,

I want to code a class or module whatever the right name is that can accept the POST from any from and enter the data into a database. Such that i can use that as the action script for all my data entry forms.

Thankx

[VGR]

easy, with some prerequisites (some are not necessary but are a save of time)
- your class/module can easily accept $_POST[] data from any other script.
- the difficulty is to map the form's fields to the DB tables and column layout
This I would solve by :
- sending- if possible - all FORM fields' values, even those resulting of unset checkboxes and unselected SELECTs ; I would probably write an OnSubmit() handler in the DHTML to rebuild a "standard" form from the "real" form and submit the first in stead of the second. If you do this with a .js script on your server, you add a bit more security than by having that javascript part directly visible in the DHTML output.
- then, considering a "standardized" form is submitted, you should also pass along a link to the DB table - I suggest an encoded form like a MD5 digest, and a server table giving you the database and table from that digest.
- then on the server, you have the database, the table, and the standardized fields. You should be able to write directly the row (will work for INSERTs ad UPDATEs given you also provide the table row_number/ID in the standardized form's data)
- alternatively, you could make sure you can write all the data in the target table by (a) checking via DESCRIBE TABLE that it's eligible, and (b) ALTERing it to reflect the data received from the form. This would require your webserver to use a DB user having a lot of privileges - this is generally seen as unsecure - think "root" (in the MySql sense, not the *nix sense ;-)

that that difficult IMHO

I already have an interactive script that automatically adapts to the layout of any table in the selected database (on the selected server) to enable data retrieval/update/delete/insert ; it even detects the keys when they are multiple and offers a standard FORM with each field mapped to the type & length of the table's layout.

it's available in source form on my server (no magick inside, though ;-)

[thepreacher]

VGR can i have a copy of your script please. Thanks

[rdivilbiss]

Having done this before (ASP not PHP) I will state that all that VGR mentioned and more crop up.

Point in fact, I think it was a very useful idea, and an excellent teaching tơl.  I practice in a medium enterprise, we found ourselves constantly having to refine the class as more and more complexity ensued.  While okay for simple straightforward forms, the class just became so complex it was too bothersome.

Over time it became easier to generate the data access methods and form data handling methods using some simpler methods and breaking free of the form class.

Having said that, there is some existing work in this area you could use to lessen your leaning curve and maybe learn from others.

http://exorsus.net/software/ Scroll down to the form classs

http://www.phpclasses.org/browse/package/1061.html

For mapping form data to fields we used a field definition table.

We also had a number of hooks within the class to outside user functions to perform any logic prior to storing the data, etc.

The developers came to dislike having the field definitions stored in the table rather than in the server side code, as it was more trouble to lơk things up.

[VGR]

agree even if I don't understand "to crop up" (despite that I think I know what is crop, it's growing in laboured fields)

I ***also*** rely ona standard include defining a site (or website part) 's database and table(s), and I use "generic" scripts that use those variables (constants, if you like) for accessing data.

This probably won't work in your case.

The script is gestDB.php and it's available on www.edainworks.com in the third-party tools offered for free. I'm not sure it's the latest version though (ie, the one with cross-browser W3C compliance ;-) but it should be a basis of reflexion for you anyway.

[rdivilbiss]

Sorry for the confusing term VGR. "Crop Up" - se produire inopinément, things would occur which were not previously expected causing us to make additional accommodations in the form class.  Not from a lack of foresight, but various forms and their underlying table structures can be very complex.

We ended up with multiple classes and very nearly created a framework.  It became very complex and difficult to teach new developers how to use all of those classes.

From those experiences I've settled on some essential database access routines along with a generic form processing script.

However, from a learning experience it was quite useful.