I'm working on a new framework for PHP that utilises an architectural pattern called RMR, instead of the more common (pseudo)-MVC that most PHP frameworks currently implement. So far it feels like a better fit for web-apps than MVC was.
I'm currently separating the various concerns involved with managing a page request/response cycle and have so far implemented objects for form validation, representing the request, representing the response, a front controller to wrap a complete HTTP request/response, a resolver to route a request to the appropriate resource and so on.
This has led to an interesting question regarding separation of concerns, however.
In an MVC framework I'd normally have a form validation object and a business object (model) wrapped in a controller action. The action would validate the input and hand it off to the business object if it passed validation, or back to the view for error display.
However, in RMR, there is no controller. The architecture I'm considering has a form validation class like the MVC frameworks such as zend, but without a controller there isn't an obvious place to invoke it.
I could invoke the form validation object from within the resource (the RMR equivalent of a model), but this feels wrong, because the resource needs to know more about how it's going to be used in this case. I know from the description of RMR that this isn't completely avoidable, the resource has to be able to understand a HTTP request, but I'd rather keep it to a minimum if at all possible so that resources can still be used outside of the context of the RMR framework without major modification.
I could do form validation in the object that encapsulates the HTTP request, but this implies that the request object needs to know how the resource is intending to use the given input. For example, a resource representing a blog entry may allow comments to be added, votes to be collected or the original poster to edit it. If all three kinds of operations are submitted via a POST then the request object will need to be able to determine whether the given POST is for editing the blog, adding a comment or submitting a vote. If more functionality is added to the blog article resource, or if some functionality is removed, then the request needs to know about it. This seems to break encapsulation.
I also considered moving form validation to the front controller, but this would have similar problems to having it in the request object. The front controller would need to know something about the inner workings of the resource before it could validate input for it.
If anyone has any alternative approaches or commentary regarding this problem I'd appreciate any input you have. Maybe this problem is just highlighting that the approach I used in the past with MVC was wrong, and having form validation in the controller wasn't the proper way of doing things?