Poll: Should FormMail have more Built In Validations?

[Giraffeweb]

I think that you are opening more cans of worms by providing validation but I can see where you can add this where you can check items on an off to be validated.

I just spent a few hours the past 2 days trying to just create an input mask for the phone and fax fields and finally stumbled upon http://zendold.lojcomm.com.br/imask/. The directions were confusing but after going through the code on the site I was able to make the input mask work, as well as send the formatting along in the plain text e-mail. I don't know if you have looked at the mootools for any of this but if not, it might cut down on some development time.

Thanks for a great, great formmail.

Judy Benedict
Giraffe Web Development

[red]

I probably qualify as a 'sub-normal' fm player - that is, I appreciate its power and value, but I am still scratching my head ??? at just about every step.

That said, I didn't vote in your local questions (gave 'excellent' in the external ones). The reason being, I'm not sure. I have some suggestions, which probably have good reason for not being done (or can't be done) but I'll put them down for what they are worth:

my assumptions are two:

1. Forms are better defended the less information they have about what qualifies them as acceptable - what is valid input, what fields cross-check each other, and so forth in the markup. Conversly, things that are kept within the fm script or a script/ini combination are more secure (and can be made even more secure with .htaccess etc.)

2. Providing a standard set of built-ins, beyond what you've got and perhaps a couple of others so commonly needed as to be no-brainers - is an always, 'almost' job - no matter how many built-ins you provide in your set, it's bound to 'just miss' on what the author often really wants to do with their conditions in real life.

So (and if I'm wrong about the 2 assumptions, you can just skip this part:
here's what would help me (I've yet to get my conditions to work at all);

1. Documentation needs some really good samples and a variety of ordinary conditional sets that we might use. The bank-credit card example is something few of us (dummy-level users) understand (and matters like '~ /regular perl expression/ mean nothing to those of us who know nothing about Perl, etc.) Russell shouldn't have to do this, and the learner shouldn't have pick their way through the forum until they 'get it' (and I find i 'get it wrong' the first half-dozen times, anyway). I think there are a number of you who really have the hang of these conditions and field validation stuff and could simply send Russell your best renderings of useful explanations and examples (which is what we really learn by) and when he has some good ones, he can cobble them together and just put them in the HTML doc (maybe highlighted as a 'don't give up' box). Ok, better documentation is needed.

2. I believe the syntax for conditionals could be greatly simplified - more in tune with the way even us dummies learned to handle the sequential logic of hand-calculators. Once we get over our initial fear of entering the 'do not touch' land of the script itself, there's no reason why we can't set a few things in the script that will make spam&hack greesers go elsewhere.

One thing is that the conditionals in the markup might more resemble the good old If..Then stuff from my Lillith and Pascal days.

Can fm pick up the tabindex from our fields? I notice that tabindexes seem to have no effect in hidden fields and they can be easily mangled without redundant patterning (as in the mail address mangles). That would be a good way to identify the field a condition applies to, and it seems more secure than identifying the field by name. I see no reason even a beginner couldn't handle that. So we write something like

"IF (4 #> 8) THEN you dummy you didn't enter the number of toes correctly!"

for specifying that the field with the tabindex=4 is a number to be tested for being gt 8 along with the message to output. literals can be handled similarly, perhaps with the '/' delimiters' and mangled as well (to prevent interpretation that might indicate which field is being tested). Of course, those who don't want their fields tabbed, need another method, but I think they are few.

Making it even harder for spammers to interpret would be to add to an author specified script setting for which stringpos is the indexed 'field identifier' and and we can mangle the tests completely. A conditional like (4 #> 8) in the markup with '$tindexpos = "6" could be rendered IF (38A#2480c9 #>8)Then "YoMANGLEu dumMANGLEy &etc." Of course, the de-mangling would have to be done before the conditionals were parsed and applied. Since the author creates both mangles and the position of the index (a two char index '00' .. '99', actually) there won't even be any pattern clues for different sites. The field identifier isn't even embedded in any fixed mangle - just anything you use to surround the index, as long as the real index is in the correct position.

The set of conditions you have seems nearly rich enough. It would also help if it could include a few combinators as well.

conventional grouping should be included as well. I'm not sure if we can group conditionals with the present set - I tried, but since my conditionals have yet to work, that was the first thing I eliminated. Anyway, it gives much greater power to be able to have expressions like

(a & b) | ( c & (d | e) ) work. Easy to build, often convenient in selecting and testing fields that cross-check each other.

That's it. Probably a squirrely idea that won't work. Take a new parsing routine, but I read those folks posting on your parsing stuff in 2008, and I think there's quite a collection of talent here. Just something that reads simple works fast and, well, perhaps can be a little "forgiving". something that can handle:

$condMangle = "some mangle"
$condpt = some user specified char that will be the insertion point for any mangles in the literals or messages of the conditional.
$indexpos = 2 digit # that gives the position the tabindex of the field being tested in the field identifier.

I think the rest goes in the markup which becomes virtually indecipherable ( is that a word?) by any but the most dedicated hackers.

Oh yes, it would be nice if the tests could handle url redirects as well as plain messages. (did someone mention that earlier?) With that we could even use our forms for little quizzes and games - pass the tests and you get to go to the....Next Form!!!???

<input type="hidden" name="dummyname" value="IF (#$$cx3094 =< #5) | (70260224 - #5030%14) & 804MANGLE75899 >= #5 THEN url(abc/deMANGLEfyi.deMANGLEf)

Even I can set that up, yes?

[borealis]

Tectite FormMail is a most useful form processor and it doesn't need "built-in" validation. It seems to me that the two products should be developed separately, instead of cluttering up the form processor. It has plenty of code lines now!
Based on the quality of FormMail, I believe that the developers could come up with a separate, kick-ass Validator that could be activated/hooked/called-into-action with a line in FormMail.

[hommealone]

Excuse me if I am wrong, but people in this thread often seem to be talking about client-side (that is, javascript/ajax) and server-side (php) validation interchangably, when they are not the same thing. And the poll question does not help matters by not being specific about which type it means.

There seem to be two distinct reasons to validate: user-friendliness, and security.

First, lets talk about client-side issues.

From a user-friendliness perspective, I like to include javascript validation for the purpose of helping the user. I believe that this is outside the scope of the formmail script itself. However, it might be helpful for many people if folks posted examples of their .js validation scripts (somew)here in the forum.

Many javascript validation scripts are available on line, and it is not too difficult to adapt them to formmail. If we keep in mind that these are not put in place to foil spammers and bots, they can be kept fairly simple. Did a user forget to fill in a field? Give them an alert and put their cursor back in the field they left blank. This is much better than sending them to an error page and making them come back to the form.

And before we leave the subject of javascript, while anything we do with javascript can be teased apart by spammers and so does not provide strong security, we CAN use javascript to make it difficult enough for spammers that they may just go somewhere easier.

Be creative; use js to 'activate' the form - perhaps changing the values of elements or writing in the submit button or form action - only after they mouse over or click something (to ensure that they are human), for example.

As far as real security issues go, I think that the creators of formmail are on the right track by strongly encouraging image character recognition challenges. If we are really concerned about security, we should implement them, and formmail gives us several options!

As far as server side php validations, I personally would like to see a more extensive, separate user guide to implementing the validation processes which are already built in to formmail. A how-to tutorial about this part of the equation. Perhaps it already exists and I just haven't found it yet! And then I would like to see more of them enabled by default, as long as it is easy and clear how to turn them off or tweak them if needed. But given the wide range of expertise of people who use formmail, perhaps it is best left as is.

So, for what it is worth, here is a javascript validation which I am using, which was adapted from the excellent tutorial on tizag.com ( http://www.tizag.com/javascriptT/javascriptform.php ).

The script contains several functions which I am not using but may be helpful to others.

function formValidator(){
    // Make quick references to our fields
    var realname = document.getElementById('name'); // formmail derived field
    var email = document.getElementById('emailaddress'); // formmail derived field
    var address = document.getElementById('address');
    var phone = document.getElementById('phone');
    var mesg = document.getElementById('mesg');
    var recaptcha = document.getElementById('recaptcha_response_field');
    
    // Check each input in the order that it appears in the form!
    if(notEmpty(realname, "Please enter your name")){
        if(isAlphabet(realname, "Please enter only letters for your name")){
            if(notEmpty(email, "Please enter your email")){
                if(emailValidator(email, "Please enter a valid email address")){
                    if(notEmpty(mesg, "Please enter a message")){
                        if(notEmpty(recaptcha, "Please enter the characters in the image")){
                            return true;
                                }
                            }
                        }
                    }
                }
            }
    
    
    return false;
    
}

function notEmpty(elem, helperMsg){
    if(elem.value.length == 0){
        alert(helperMsg);
        elem.focus(); // set the focus to this input
        return false;
    }
    return true;
}

function isNumeric(elem, helperMsg){
    var numericExpression = /^[0-9]+$/; // you may need to add characters like hyphens, periods, etc for yourself
    if(elem.value.match(numericExpression)){
        return true;
    }else{
        alert(helperMsg);
        elem.focus();
        return false;
    }
}

function isAlphabet(elem, helperMsg){
    var alphaExp = /^[a-zA-Z ]+$/; //-- includes space character (after Z) 
    //var alphaExp = /^[a-zA-Z]+$/; //-- w/ no space character
    if(elem.value.match(alphaExp)){
        return true;
    }else{
        alert(helperMsg);
        elem.focus();
        return false;
    }
}

function isAlphanumeric(elem, helperMsg){
    var alphaExp = /^[0-9a-zA-Z]+$/; // add spaces or characters as needed
    if(elem.value.match(alphaExp)){
        return true;
    }else{
        alert(helperMsg);
        elem.focus();
        return false;
    }
}

function lengthRestriction(elem, min, max){
    var uInput = elem.value;
    if(uInput.length >= min && uInput.length <= max){
        return true;
    }else{
        alert("Please enter between " +min+ " and " +max+ " characters");
        elem.focus();
        return false;
    }
}

function madeSelection(elem, helperMsg){
    if(elem.value == "Please Choose"){
        alert(helperMsg);
        elem.focus();
        return false;
    }else{
        return true;
    }
}

function emailValidator(elem, helperMsg){
    var emailExp = /^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,4}$/;
    if(elem.value.match(emailExp)){
        return true;
    }else{
        alert(helperMsg);
        elem.focus();
        return false;
    }
}

p.s. - to implement this script, you'd use:

<form method="post" action="[...]formmail.php" name="form_name" onsubmit='return formValidator()'>

[Stronghold]

I voted no. I think it's doing well how it is.

[keithlarson]

Your FormMail is very good. Any additions would only make it better!

[Plaka]

Tectite FormMail is a most useful form processor and it doesn't need "built-in" validation. It seems to me that the two products should be developed separately, instead of cluttering up the form processor. It has plenty of code lines now!
Based on the quality of FormMail, I believe that the developers could come up with a separate, kick-ass Validator that could be activated/hooked/called-into-action with a line in FormMail.

I agree server side validation called in a cryptic fashion maybe the best way to go. As for the complexity simple TRUE/FALSE toggles would work for most.

Great script thank-you.

[warriorone]

I believe we should have the option either allowing or disallowing the use of html code.
In my opinion the more validations the better as it discourages spammers ,
The downside is that the more validations the more bugs and errors are likely to creep in

[bgarnick]

yes please this is crucial.

[duongico]

I love tectite's formmail so much that I recommend it to every web designer. Working on a project that client wants server-side validation, as a result I am forced to look for other option too. Could formmail works with javascript/ajax validation? Someone in this thread mention about the Dreamweaver validation feature, what it is about? Please elaborate.