Forums

Don't know of any good server-side validation tutorials for ChronoForms - what kind of thing do you have in mind??

The ordinary stuff, actually.😉

-> Form is submitted. (Server-sided) Script validates fields. And either the form is re-displayed incl. error messages, or it's being processed (mailed, added to a database, whatever).

Has anybody already done this in a solid combination with ChronoForms?


TIA<br><br>Post edited by: davewolf, at: 2007/08/28 04:23

Hi davewolf,

Well, the basic emailing and adding to a database are supported directly by ChronoForms.

You can use the two OnSubmit (before and after email) to add any processing that you want - the Form data is available to you in the $_POST variables.

This processing can include validation, I think I posted a hack in the forums here for doing some validation and re-showing the form page with the submitted data.

Bob

Hi davewolf,

Well, the basic emailing and adding to a database are supported directly by ChronoForms.

You can use the two OnSubmit (before and after email) to add any processing that you want - the Form data is available to you in the $_POST variables.

This processing can include validation, I think I posted a hack in the forums here for doing some validation and re-showing the form page with the submitted data.

Regarding the server side validation, I see some requests for it and so I will try to have a solution soon, but what I have in mind now is that the form action URL should be the same as the form URL, the 2 functions at chronocontact.php will be combined and we will switch the code by checking if this is a submitted form and VALID, if you are in rush then you can try doing this yourself, I am planning to have it but not sure when exactly as there is too many other earlier requests too🙂

Raincheck! Have to run some tests first...

This processing can include validation, I think I posted a hack in the forums here for doing some validation and re-showing the form page with the submitted data.

Any chance you know where to look for that? I tried your nickname + "validation" at the search box, but didn't get a decent result I think.

Okay, let's break this down. (I'm sure you know the following stuff, just want to make sure you know where I'm coming from.)

What we need (basically):

- validation - checking, you know the drill + creating error messages if necessary
- form - displaying the form, incl. error messages if already submitted, but not successfully validated
- email - processing the input, can be an email, db insert, whatever

Onward. A one-script-for-everything is the common way nowadays, I suppose. To accomplish that we need a PHP code entry which should be executed before the form is being displayed.

Plus an option to let the script check for a, let's say, 'chronoform_validated_flag'. If it is set to 'true' (by the user code) then the form won't be displayed any more, but the email sent (or whatever), else: the form (again), but no email.

Everything else - the validation & form code - can be handled by the users right now.

Other than that I don't see a way to keep it all together and not just just Chronoform to display the form and write everything else around it by ourselves (incl. redundand code, like the email processing).

Maybe I'm missing something, but that's my point of view.


TIA for any reply.

Hi Dave,

Thanks, that's helpful. I'll give you a more detailed answer later today but here are my first thoughts an how to handle this with the current ChronoForms (Max has already posted that he's looking at some new functionality for a future release).

As I see it, the logic goes like this:

1) display the basic form for entry (already handled by CF and with some client side validation in v2.3)

2) onSubmit run some PHP for validation (functionality exists with the 'OnSubmit - before e-mail' code box)

3a) if valid send the e-mail and/or add to the database (already handled by CF)

3b) if not valid, add error messages and redisplay the form showing the submitted data and the error messages (not natively handled by CF).

One way I'd deal with '3b' now is to include variables for the form values and the error messages in the form html with initial 'null' values i.e. value_1 = ""; $error_1 = "";. In the php validation routine you can reset these to different values, then re-call the form display function.

I'm sure that there's more to it than that and I'll try a worked example later but I think in principal this will do what you want.

BTW the earlier post that I had in mind was this one which is a code hack to show a personalised thank you page. I'll see if it's possible without the code hack.

Bob

Thanks for the link.


As for the proposed way to handle cs (client-side) validation, I recognize most of it. There's a lot of some of the other stuff I thought about. But there are also some issues.

Most important one: onSubmit.

I certainly suppose the onSubmit stuff is called by a JavaScript function. Then it's no good to put the cs val. code in any of these onSubmit boxes. Because, somebody just turns of JS, no cs validation. Big no-no. The whole point of cs val. is to provide a solid validation if JS val. is off or failed.

If the JS val. works as planned, cs val. might not even be necessary...

Hi Dave,

Sorry I wasn't clear enough. ChronoForms does support JavaScript client-side validation - both through the new Validation functionality, or through putting custom code into the 'Form JavaScript' box. Of course, you are correct, neither of these will work if the client has JavaScript turned off.

On the 'Form Code' tab there is also an 'On Submit code before sending email' field. This one doesn't use JavaScript but any PHP that you post there will be executed before the e-mail is sent, so this is the location to use for server-side PHP validation.

Bob

On the 'Form Code' tab there is also an 'On Submit code before sending email' field. This one doesn't use JavaScript but any PHP that you post there will be executed before the e-mail is sent

Alright. (I haven't yet looked at 99.9% of the actual CF code...)

Next issues then...

Suppose the approach you described above, we run into some other problems. E.g., unless you want several forms displayed on one page, you of course have to send a fresh page, which also means a new HTTP request, thus new script execution. We're not talking of one script to run it all, but of several calls between whom variables would have to be passed on. (Not sure if that's still English, but I hope you get the drift...) Now, introducing, let's say, session handling, just for (one-page) form processing is a bit of an overkill to me. But it's the almost inevitable result of validating after sending the form. You'd have to send the already submitted data to a new form / page / script.

I'm not a programmer per se. So correct me if I'm wrong.

Hi Dave,

You've got your finger on the main problem - and the reason why client side validation is preferred.

My suggestion, and implicit in Max's too is that you keep the data in the form code. That way you avoid the need to set up sessions - or any other temporary data storage.

The two bits of data that you need are the submitted value, and the error message and I think that both can be written in the form code with a little ingenuity.

Unfortunately I've spent the afternoon struggling with a couple of other Joomla extension and haven't yet had time to put a test together. Not forgotten though.

Bob

Hi Dave,

Here's a demonstration in principal - but it does need a small code hack.

The hack is this:

(a) in components/com_chronocontact.php add '$validate = array();' around line 14

(b) in the same file look for function showform() and add 'global $validate;' just below it.

(c) do the same for the function uploadandmail() in the same file.

(d) in the file components/com_chronocontact.html.php do the same for function showform()

Now we can use the $validate array to pass information

I created a very simple form with the following html code

<?php
$name_valid = 'none';
if ( $validate['name_error'] ) {
  $name_valid = 'block';
}
?>
Name: <input name="name" value="<?php echo $_POST['name']; ?>" type="text"><br />
<span style='display:<?php echo $name_valid; ?>;' >Error in name field.<br /></span>

Email: <input name="email" value="<?php echo $_POST['email']; ?>" type="text"><br />

<input name="submit" value="Submit" type="submit">

and the following code in the 'On Submit code before sending email' field:

<?php
$error = false;
if ( !$_POST['name'] || $_POST['name'] == '' ) {
  $validate['name_error'] = true;
  $error = true;
}
if ( $error ) {
  showform();
}
?>

This form has trivial validation - it just requires something in the 'name' field. If you leave the name field blank but type something in the email field you'll see that this is preserved.

I do agree that this is not an ideal solution but it does demonstrate server side validation with minimal changes to the code base.

Bob<br><br>Post edited by: GreyHead, at: 2007/08/29 21:11