Jump to content

Newbie Design Question to implement multiple forms and database queries


Recommended Posts

Hello

I am designing my thrid project in PHP/MySQL. I have a question. In my app, I have to insert user details and couple of info in multiple pages based on sections ie. personal, address, educational marks, etc.

1.) What do you people suggest to implement it? Shoul I have multiple PHP pages each implementing a single form or should I keep the form details in separate pages and just include them in a common PHP page. I will then need to keep track of the page to be displayed using some hidden form value or some session variable.

PS: Each form change does and insert or update regarding that info so we should keep that in mind.

2.) Also, how do you people keep your MySQL queries? Do you write queries in place like:

$query = "select foobar from sometable";

$mysql_query($query);

everywhere or you use some other design methods?

Ritesh
I typically separate the process of retrieving data from a database and the process of formatting and displaying it.

A simple example is if I'm writing a forums application.  I might have forums.php which handles all of the forum logic such as how everything is displayed, who sees what, etc.  But I do not put any SQL into that file.  I separate it into another file, maybe forumsDAO.php, and this file contains functions to retrieve any necessary data from the database.

It's one more file to maintain and keep track of, but let's say my site has been finished for 6 months and now I want to go back and redesign the database but only the database.  Now the only file I have to go in and edit is forumsDAO.php and as long as it continues to provide the same functions (or interface) to the DB, forums.php will continue to work without any changes.

This isn't exactly how I set things up, but it's a simple example to get the point across.

Long story short, I don't like to have MySQL queries sitting in data objects (php classes) or in any code that strictly handles page layout.
As for your question about forms, my recomendation is to design a form class that handles all basic handling required by every form.  Build in the ability to add any type of fields to the form, some basic validation and a way of declaring which fields follow which validation rules, etc.

After you create this class, let's call it CForm, you create another class for your current application.

[code]
class CMyAppForm extends CForm{
}
[/code]

Now in CMyAppForm, you include all of your application specific fields in here.  For example, let's say you have a page for registration, another for editing information, maybe one for account transfering, etc.  Each of these pages is likely to have a first name field.  On every page where you use this field, do you want to have to re-type all of the code to lay that field out, validate it, etc.?  Or do you just want to do this:

[code]
$form = &new CMyAppForm();
$html .= $form->GetField_FirstName();
[/code]

and then when it needs to be validated:
[code]
$form = &new CMyAppForm();
$valid = $valid && $form->ValidateField_FirstName();
[/code]

With this approach, every page in your application that has a first name field in a form will behave and validate the same.  If you need to change its behavior, it's in one location.  Also, it eliminates confusion from your users about how come that field behaves differently on 3 out of 5 different pages?

Lastly, the reason you extend your CForm with CMyAppForm is later when you create a new application, you can create a new class CMyOtherAppForm that extends CForm.  This way, you can have all of your application forms using the same logic, which makes it easy to fix if there's a glaring problem with security or something else.  Also, your applications can still have independence from each other; who says a First Name field in application A behaves like the one in application B?

Hope that helped.
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.