Rob Allen wrote:
Matthew Weier O'Phinney wrote:
-- Rob Allen <[EMAIL PROTECTED]> wrote
The main intention of the request object, from my perspective, was to
allow determination of the controller and action values. Any class
extending the basic request abstract is simply adding more places
from which to retrieve that information.
Conceptually (to me at least), the request object is an encapsulation of
all data from the outside world into the application.
Actually I think using the request object for the controller and action
values is a logical extension of encapsulating the request -- not the
other way around. I makes sense for those values to be there because
actions often need to know them.
I think one of the reason there is some friction here is that the
Filter_Input interface is procedural and the next step up is what Fowler
alludes to as an Input Controller, which is the quality of processing
inputs that all controllers have.
So instead of doing inline the conceptually wacky (return value or false?):
$alphaName = $filterPost->testAlpha('name');
$email = $filterPost->testEmail('email');
if (($alphaName !== FALSE) || ($email !== FALSE)) {
} else {
You would create a Input Controller with a Validator and in the
initialization do something like:
$this->addRule('name', new Zend_Rule_Alpha('Only letters allowed'));
$this->addRule('email', new Zend_Rule_Alpha('Not an valid email'));
And then:
if (! $this->isValid() ) {
$errmsg = $this->getErrorMessages();
} else {
Each action in a controller can set specific rules and filters, and a
validation logic can be centralized (in the View for example) rather
than spaghetti code in each action.
