Form with server side validation: user can't correct input


I’m facing the following problem:

I use a form with connector to php and Dataprocessor. As long as valid data are sent by the form, everything works fine. When I try to do some server validation of an email field, and validation is false (meaning: an invalid, an error or a custom response is set…I tried all three of these), the error message is processed correctly. But when the user corrects the error (by editing the email adress field), Dataprocessor (I presume) does not want to send the corrected form again. So, even after correcting to a valid mail adress, the form is not sent anymore, no matter what the user does. In FireBug, I don’t see the request happening anymore. When I refresh te page (F5), everything works again until the first server side validation error is hit, and the problem starts again. Some code snippets:

On server:

function check_userAccountFields($data){
    if (!filter_var($data->get_value( "mail"),FILTER_VALIDATE_EMAIL)){

    if (!filter_var($data->get_value( "username"),FILTER_VALIDATE_EMAIL)){
return $data;


On client side:

manageUserFormDP = new dataProcessor("manageUserForm.php");
      manageUserFormDP.setTransactionMode("POST", true);

                loginVars.myStatusBar.setText("<span style='color: red;'>Email adress is invalid</span>");
                return true;

What am I doing wrong?

Also: I’m confused about the function of the return true statement (last code line). What is it supposed to do exactly? Anyway, setting it to false or even omitting it doesn’t change the behaviour of the form…
And what is the “response” variable supposed to contain ? How to retrieve that information and make it visible in the error message? Some more detailed documentation on server side validation would be welcomed.

Beste regards, Maxx

Ok, figured out today that I can solve this by issueing the form.resetDataProcessor(“updated”) method just before the method. Not very elegant though: why is it that when the form has already been validated as correct, you still need this separate reset command? One would expect that “validated” already means “ready for saving”.
Also, it means that saving a newly created record always has to be done by a separate line of code with another save() command, since in that case I should use form.resetDataProcessor(“inserted”).

However, my questions about the exact function and use of the ‘return’ value, and more documentation about using the content of the ‘response’ still remain open.

Beste regards, Maxx


I can confirm the issue, we will update the code of the form, so returning an error response will not block further form saving.

However, my questions about the exact function and use of the ‘return’ value, and more documentation about using the content of the ‘response’ still remain open.

Returning false will prevent default post-processing of data saving. It has sense to return a false, when you are using your own statuses, which can’t be processed by the dataprocessor ( status:“confirmed” or any other non-default value )

As for response it is an XML tag object, from the server side response. You can use a connector’s api to save extra in info in the server side response. … eattribute

And after that, on client side, you can use response.getAttribute(name) to get those values.

Ok, thanks Stanislav, that helps a lot.

Actually I get the response on the client side with response.childnodes[0].nodeValue, as it is a textnode set with set_response_xml on the server side.
I think it would be nice to mention this in the docs, as wel as the fact that on the server side only error() and invalid() prevent saving the invalid data, and all the other statuses save even invalid data in de db. For instance, is there a way to do avoid saving invalid data when using set_status()?
If not, maybe an option for future versions?

Best regards, Maxx

set_status is not supposed for DB saving control, this command can be used to provide a status value to the client side.

In custom data saving handler you can use one of the next command to prevent default DB saving logic.

$action->success(); //mark operations as correctly finished
$action->error();   //mark operation as error
$action->invalid(); //mark operation as invalid