PHP Form Processing - Distributed or Centralised?

Question

I've searched around but there doesn't seem to be a clear consensus on which one is better. Currently, all the HTML forms on the site point to a single PHP file. Each form has a hidden input specifying the action (e.g. 'user-login', 'user-logout'), and the PHP file calls methods from that.

So my question is: Should I point each form back to itself, related forms to a single file or all forms to a single file? And in terms of MVC, should processing take place in the controller or form?

Answer 1

Should I point each form back to itself, related forms to a single file or all forms to a single file?

You should point everything to index.php, which then delegates other components (controllers in MVC terms) to take care of the processing. The controller will then decide which view it wants to render. index.php would be in this case something we call the front controller. (note: below I am recommending ZF1 as a learning platform. ZF1 has a "front controller" class. Some people may argue that THAT one is the front controller and index.php is what they call the entry script. In my opinion, that is only the second "front" controller. Nevertheless, both opinions are controversed, so make your own opinion).

And in terms of MVC, should processing take place in the controller or form?

In terms of OOP first and foremost: the object is the only one who knows how to validate its own data (the principle of self-containment), so the form should validate itself. If it's about a model, the model should be called by either the controller, or the form - it's a matter of taste. No matter which way, the same principle applies: you feed the Model with data and call its validation method.

As you may have noticed, the Form class is a Model.

Don't let yourself fooled by the hype called MVC. Respect the OOP principles above all.

Regarding MVC: the MVC pattern says: the controller only coordonates the other components, for instance it takes the input, creates a Form instance, and calls the Form's validation method.

I advise you to use a framework to better see how all these pieces work together. The best would be zend framework 1, which has little to do with real life requirements, BUT which is a masterpiece in terms of patterns and practices.

Maybe ZF2 will change that mistake with the extra front controller.

---

Looking at the other answers, I feel the need to clarify some terminology used in my answer:

• Model is a model. There's plenty of documentation about MVC
• Form is a subclass of Model. It takes care of the validation. It may also have a method Form::__toString() which renders the HTML form in the view (the V in MVC)
• view is the html file, and it's rendered under the supervision of the controller (C in MVC)

---

To recap, the overall execution flow would look like this:

1. <form action ...
2. entry script (a front controller)
3. router (it decides which Controller to forward the request to)
4. the Controller coordinates all the actions, calling the Model::validate() of one or many models (including Form, which is also a Model)
5. in the end, the Controller choses to render() a view (a html file), which could contain a call to Form::__toString(), in which case the Form is a hybrid of Model and "renderer".
6. Fun
7. Profit

That's it, basically. Different frameworks have different data/execution flow. ZF1's looks like this for instance: http://www.slideshare.net/polleywong/zend-framework-dispatch-workflow

Answer 2

In my opinion you should use one file for each purpose. Same as mvc structure, this is a good approach for programming and it will be helpfull when your code gets really complicated.

Answer 3

In MVC terms your processing should take place in the controller. You shouldn't have any processing logic in your form (the view). Whether you have a different controller for each form is up to you. You could, for example, have a single controller that accepts all form submissions and performs some common processing (such as csrf detection) and then invokes your other controllers for each form. Alternatively, you could have a single controller that loads validation requirements from a database and behaves differently depending on which form has been submitted.

Answer 4

In MVC terms, making all form point to a single script means you've got a Front-Controller for Forms. There is one controller that deals with form requests.

Should I point each form back to itself, related forms to a single file or all forms to a single file?

That depends on your needs and the design maybe even architecture of your site.

And in terms of MVC, should processing take place in the controller or form?

Processing in MVC normally takes place within the controllers (lightly only) and the models (heavy processing). So if you're looking for an exemplary MVC design implementation you most probably will have Form Models that are used by the Controller(s).

This will ensure that you can make use of forms more flexible and you don't duplicate code for form processing within your application.

Answer 5

You question closely relates to the Front Controller Pattern. In my opinion you lose nothing with pointing verything to a certain script, but win the flexibility do execute certain actions without having to repeat (and probably foget at some place) those actions.

So I would recommend to point all forms to one script.

Btw. it is the controller who handles the form processing in terms of web MVC.

Answer 6

Following on from my comment on Flavius' answer.....

The object encapsulating the form should be used for both presenting the form to the user and retrieving data sent back from the user. Using 2 different codesets to operate on the same dataset undermines the principle of encapsulation. Consider if your login form has a name and a password field. If you decide you want to process a sha1 hash of the password in place of the original value, you may have to modify 2 bits of code in 2 different places!

This does not mean that both instances of the form object need to be implemented within the same URL path; consider PHP's 'require' and auto_include constructs.

Where multiple input sets are multiplexed via the same URL path, this is referred to as a Front Controller pattern.

There are benefits and issues with Front Controller vs the more distributed approach.

Front Controller:

• allows common processing to be implemented in one place only (e.g. authorization, logging)
• moves structure of the application away from filesystem layout and into code, therefore control over application structure implemented within code
• simplifies handling of bookmarks

Non Front Controller:

• much easier to support
• application structure evident from webserver logs
• more robust - since breaking one script deos not break whole site
• better performance - no need to load huge amounts of redundant code / deferred loading of processing target