Thread: Question from Tutorial

Hi,

I really like all the tutorials - they are easy to follow but sometimes raise as many questions as are answered! (for me anyway)

In this case - as per the example in Forms Tut 2 - as usual I follow what's given but.. what happens to the password/password change data when you hit the submit button- where does it go? -what is updated, where? if this is a mailto example - how does this work in practice?

This leads into trying to understand how to store and use the data captured on any form other than as an email.... before I tackle the Advanced version

Any help appreciated!

Roy

The form field values are stored in an array in which the key is the field name and the value is what the visitor has filled in. This array is $_POST which is then broken, either by using generic loops or specific scripts, to it's single elements. From that point on, what happens depends on the script: it is sent to the form owner as email, or stored in a database, or writen in a file, or a combination of the above.

Thanks for the answer - I know that my next question coming down the tracks will be how to use the data that gets placed in the db! but I'm not there ...yet ..any advice or comments in advance?
Roy

There are two ways of retreiving the database data: one, for non pros, is to use the phpMyadmin (you can find it in your CP, in the section "MySQL Databases, in the bottom of the page). It will allow you to connect to your database, look at the tables of the database, select a particular table (f.e. "clients", or "products" or wharever), and then display, edit, delete or add new records.

However this is more or less like having all the info writen in a piece of paper, it's not very useful.

The correct approach - but this requires a specific script - would be that of having a specific application (script) that would allow additional features: all of the above, but also displaying and being able to edit the records directly on your website (in that case these pages could be part of an authorised users area (if required) or not, depending on the application you are building), use the records for various purposes (f.e. mailing to all members, or calculating the stock value of a company's stock of spare parts or whatever else you can imagine of). Even more, these scripts can look through and establish relations between the databases (or between tables of the same database). That's known as RDBM (relational database management) .

Large companies use custom scripts. The can afford paying for the construction of such applications. However, small companies, use commercial scripts that come at a lower price and will allow more or less the same things. There are membership management scripts, dating scripts, property sell/buy/hire scripts, and many others. The problem with these scripts is that they are limited to their own database, and cannot comunicate between them, they cannot establish these "relations" between the different databases)