On integrating Filter and Input. Are we sure?

[jakejohns]

For some time I have been excited about the Filter_Interface package, and the ability to integrate Input and Filter. However, now I am questioning if that's right.

Filter is for validating and sanitizing. That's my domain logic, right? Input is mainly about describing (HTML) inputs. That's presentation, right?

I don't need to inject an object into my domain that describe the inputs. I need to take the output of my domain (errors), and pass them to the thing describing the UI, no?

// Domain
class CreateThing
{
    //...
    public function __invoke(array $input)
    {
        $this->payload->setInput($input);

        // No reason i need to know about describing HTML UI stuff here
        if (! $this->filter->apply($input)) {
            $failures = $this->filter->getFailures();
            return $this->payload
                ->setStatus(Status::INVALID)
                ->setOutput($failures);
        }

        //...
    }
}

// Responder
class CreateThingResponder
{
    //...
    protected function invalid()
    {
        $this->response = $this->response->withStatus(HTTP_STATUS::INVALID);

        $this->view->setScript('thing/create')
        $this->view->addData(
            [
                'input'  => $this->payload->getInput(),
                'errors' => $this->payload->getOutput()
            ]
        );
        $this->renderViewToResponse();
    }
}

// view: create/thing.php

$form = new CreateThingForm;

if ($this->input) {
    $form->setInput($this->input);
}

if ($this->errors) {
    $form->setErrors($this->errors);
}

// This is the only time i need information describing the HTML UI
echo $this->render('form', ['form' => $form]);

Are we sure Input needs to know about validation outside of just understanding that errors exist?

Since Input has been stuck in 1.x land, here's how I've been doing things for a little bit: https://github.com/jnjxp/jnjxp.form

Thoughts? Maybe I'm wrong, but I kinnda think Input should just deal with describing UI stuff, and not know about validation and sanitization logic.

[harikt]

Hi @jakejohns ,

Thank you for your inputs, questions and concerns. Some how I missed this. Sorry for the long delay.

Filter is for validating and sanitizing. That's my domain logic, right?

Yes you are right. Validation and Sanitization depends upon the domain.

Input is mainly about describing (HTML) inputs. That's presentation, right?

Yes.

So may be we only need a way to setErrors and setValues for the field.

[harikt]

Hi @rk ,

As you shown some interest on the Aura.Input . Do you have any inputs on this issue ?

It may help to push things for 3.x .

[rk]

@harikt and @jakejohns,

If we're talking about splitting input validation and sanitization off to its own package, I see that several packages may be required for separating concerns properly. I'm a proponent of the FormModel pattern, which is really composition of several parts:

• Domain logic of the form itself (which may also be encapsulated in the FormModel itself)
• Input definition for HTML output
• Validation/Sanitization
• Etc...

Splitting out the filter logic from the Aura.Input into its own Aura.Filter package would help. However, we already have the Aura\Input\Form class that sort-of functions as a FormModel—it's only reason for existing (above that of the Fieldset class) is the built-in Anti-CSRF functionality.

I'm for splitting Input into Input/Filter packages. I think we may need a package for a FormModel abstract/interface, and to serve as an example for more junior programmers who don't understand how to work with the decomposed packages.

[harikt]

Hey @rk ,

Probably you missed it. The https://github.com/auraphp/Aura.Filter is already a separate package which is a standalone Validation and Sanitization component / package .

We have a https://github.com/auraphp/Aura.Filter_Interface ( new one ) which is trying to bind the Aura.Input ( this package ) and Aura.Filter .

The question was whether it is good to have Filter inside Form.

From your message above I do get your opinion. And something that strikes me, Aura.Input is not a presentation itself, and you can get errors out from it. So it doesn't bind anything here. Probably Aura.Input itself is some what tied to your domain, so your Filter can also be part of domain. So I don't see any problem for the current time.

@jakejohns thoughts ?

[harikt]

Hey @jakejohns , @pmjones , @koriym ,

I am in favor of integrating filter with input and move for 3.x. If any of you don't have a strong opposition I would love to close this.

[harikt]

Hey @jakejohns ,

I am closing this issue. If you still have a problem we can re-open it.