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 !