Forms: ignore form control when obtaining values

ZZromanZZ

Hello,

my idea is add a flag to some form controls which i don`t want to obtain in $form->getValues() function.

Example:

$form->addText("someInput");
$form->addText("someIgnoredInput")
	->setIgnored();

$form->getValues(); // array("someInput" => "value")

Use case:

Sometimes, I need form controls for eg. spam protection (fake email input, robot-check questions etc…) which I don't want to store to database. Explicit unset after getValues() is IMHO uqly. Function setIgnore() is talk enough, I think.

Is it worth it?

P.S. Don't confuse with setDisabled() function. It's not the same.

//edit: I already have an implementation ready to commit.

Last edited by ZZromanZZ (2013-03-27 10:12)

Jan Tvrdík

Is it worth it?

No. Explicit unset in submit handler is just fine.

Majkl578

-1 on this.

hrach

I like this. It's really common usecase: password2, captcha, etc.
Edit: I like the idea, I let the implementation without comment.

Last edited by hrach (2013-03-31 23:55)

enumag

I'm sort of unsure here. I hate the unsets in the onSuccess handlers but I don't think the form declaration is the right place for this. It's not reuseable, imagine that you need same form in several places and each one needs different set of values from the form.

+1 for the idea, –1 for implementation though.

For now I solve this by putting the unwanted fields into a separate container.

paranoiq

is this feature absolutely necessary? if the answer is anything but “yes, indeed”, than it should not be implemented this way. unset() is just fine

Filip Procházka

This is just plain wrong.

Lopata

While I'm not sure I really favor this particular implementation, I also agree that the ubiquitous unset calls are downright annoying. Since the purpose of the additional password2 or spambotCheck fields is exclusively to ensure a successful validation of the form, to a large extent it would make sense if their values were not included in the ArrayHash returned by getValues() as it is supposed to only contain the actual, usable data. Such behavior would also probably be more consistent with how the method already acts at this point in time — it does not return the CSRF token, for instance, even though it is also actually a value of a form field. Although I have no idea how to solve this problem, I am convinced that it should be acknowledged that these form fields share the same purpose and as such should be handled identically by the framework.

David Grudl

Implemented in 2.1 via setOmitted()