[thelist] PHP - centralised processing for multiple forms

Robert Vreeland vreeland at studioframework.com
Tue Sep 5 00:03:14 CDT 2006


To begin with, you can put all your validation routines in a single include
file located at a given location that the form action page can then include
- if your coders know the location of the form relative to the document root
they can build the include call. Next, at least how I do it, put your
regular expressions in a class. Then, for each form, you can write a
validation class which inherits the regular expression class and is called
by a switch statement. I use a hidden field in each form to identify the
form for the case in the switch statement with the default case being an
error message to the effect that the form data was unrecognized. As long as
your form specific validating class knows what fields to check for you can
also validate that only the form specific fields, including missing fields.
I usually have each validating class return a formatted  output string which
the calling page can then output however. Since each form has its own
validating class you can do what ever data handling functions needed in the
class - db writes, emails etc.. If you can identify fields common to all
forms then go ahead and include the validation routine in the inherited
regular expression class. You can then give your coders a stub to include in
their forms ( the include statement ) and have the forms point to themselves
as the action.

If you don't get any better ideas from others on the list, feel free to
email me off list and I'll send you some example code.


Sincerely,
Robert Vreeland
Managing Partner 
StudioFramework 

-----Original Message-----
From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On Behalf Of Paul Bennett
Sent: Monday, September 04, 2006 11:57 PM
To: thelist at lists.evolt.org
Subject: [thelist] PHP - centralised processing for multiple forms

Hi all,

I've been racking my brain over this one for a few days ...

We currently have forms of all descriptions strewn over our site. Each form
is a php page full of spaghetti code which controls (and I use the term
loosely) the display, validation and emailing of form data to interested
parties.

The forms can be anything from resource consent submissions to requests for
information to feedback on the site etc etc .

I've hated working with the 'templates' since I started - they're buggy,
easy to break and nasty to work with. Lately I patched a security hole in
one and then realise there would be other vulnerable pages on the site.
Rather than going through and reworking tens of different files, I'm now
looking for a way to build a centralised processing script / app for all our
forms. (We're talking PHP here..)

Any ideas of thoughts are welcome - my progress so far follows:

Requirements:
* html coders to be able to quickly and easily get a form running
* html coders to be able to tightly control visual display of forms (i.e. -
no templating systems, no apps which generate code)
* html forms need to be able to be physically located anywhere in the site
(no central 'forms' directory)
* script /app needs to validate data, show an error page if data isn't
valid,  email form contents to appropriate staff (enter data into a db if
required) and display a confirmation page containing all the sent data

Issues:
* config - how does a centralised app know what validation rules apply to
the form data without allowing the client to set them (and thus open up
security holes)?
* how can I avoid having the html coders produce config files for every form
(to overcome the above validation issue)?
* how can I avoid wrapper / controller scripts needing to be built for every
directory containing forms (to allow the user to remain in the same folder
location while the central script does the processing)?

Am I making sense? I feel like I'm just not seeing something right today...

Paul
-- 

* * Please support the community that supports you.  * *
http://evolt.org/help_support_evolt/

For unsubscribe and other options, including the Tip Harvester and archives
of thelist go to: http://lists.evolt.org Workers of the Web, evolt ! 




More information about the thelist mailing list