Smart or Stupid (CFLOOP as a GOTO)

This may be a VERY dumb question, but I'm brain fried. Okay - so I'm working on a form and I need to validate fields for many things.  Taking "email address" for example I need to validate that it's been filled in (not zero length), that it's less than 255 characters (the database limit), that it fits a email format and finally that the email address isn't already in use. What I'd like to be able to do is check through all these validations.  The instant a problem is found I want to stop checking.  I would then redisplay the form and so forth. In a custom tag or function I might, when an error is found simply "return" to the caller with the error information.  Since this is a rather small set and is only the first of many small forms I decided (perhaps wrongly) to just do the validation at the top of the page. To simulate a components ability to return at any point I wrapped the whole validation block in a CFLOOP from 1 to 1 (1 iteration) - as soon as I hit an error (and set the error variable) I CFBREAK.  Right after the loop I check the value of the error variable. Now that I'm looking at it I'm not sure... is this just the stupidest thing you're ever heard?  Should I take the extra time and create a customized validation custom tag for each and every form? Jim Davis

Why not use the condition attribute? <cfloop condition="theForm eq valid"> ----- Excess quoted text cut - see Original Post for more ----- The > instant a problem is found I want to stop checking.  I would then redisplay > the form and so forth. > > In a custom tag or function I might, when an error is found simply "return" > to the caller with the error information.  Since this is a rather small set > and is only the first of many small forms I decided (perhaps wrongly) to > just do the validation at the top of the page. > > To simulate a components ability to return at any point I wrapped the whole > validation block in a CFLOOP from 1 to 1 (1 iteration) - as soon as I hit an > error (and set the error variable) I CFBREAK.  Right after the loop I check > the value of the error variable. > > Now that I'm looking at it I'm not sure... is this just the stupidest thing > you're ever heard?  Should I take the extra time and create a customized > validation custom tag for each and every form? > > Jim Davis

That's only checked (as far as I understand it) before each iteration, not throughout the processing. In other words setting "theform" equal to "invalid" will not stop processing immediately - it will finish out the rest of the code in the loop THEN stop. Jim Davis ----- Excess quoted text cut - see Original Post for more -----

> That's only checked (as far as I understand it) before each iteration, not > throughout the processing. > > In other words setting "theform" equal to "invalid" will not stop processing > immediately - it will finish out the rest of the code in the loop THEN stop. What about using a cftry/catch block? Put a cftry around it (forget the loop entirely).  When you encounter a validation issue, cfthrow with your error message. Then, in the cfcatch, do what you need to do when you want to stop the processing. <cftry>       <cfif emailIsInvalid>             <cfthrow type="myValidation" message="The e-mail address is invalid.">       </cfif>       <cfcatch type="myValidation">             <cfoutput>                 #cfcatch.message#             </cfoutput>             <cfabort>       </cfcatch> </cftry> ------------------------------------------- Scott Brady http://www.scottbrady.net

I could - I was just hoping for a quick(er) fix. I guess I'm also being a little silly... thinking that CFTRY is only for "pure" errors, not validation rules... But I probably should use it... it does make perfect sense. Jim Davis ----- Excess quoted text cut - see Original Post for more -----

Why not just use JavaScript client side and then use CF server side? I could - I was just hoping for a quick(er) fix. I guess I'm also being a little silly... thinking that CFTRY is only for "pure" errors, not validation rules... But I probably should use it... it does make perfect sense. Jim Davis ----- Excess quoted text cut - see Original Post for more -----

> Why not just use JavaScript client side and then use CF server side? JavaScript will be added later - but first I want to ensure that lacking script everything still works as it should (a practice I highly recommend). Jim Davis

Ususally I stick to the if than else routine, but I think I'd try the different options mentioned here and see what works better.  I'll bet it looks a hell of a lot cleaner :) > Why not just use JavaScript client side and then use CF server side? JavaScript will be added later - but first I want to ensure that lacking script everything still works as it should (a practice I highly recommend). Jim Davis

When you're done, can you let us know which site it is, so I'll put it on my list of sites never to go to?  I HATE forms that tell me somethings wrong, I correct that, then it says something else is wrong.   Then when I go back, usually my last input is removed from the form so I have to fill it all out again.   Yahoo mail is like that.  It can take half an hour or more to create a yahoo mail account.   You have to go back and change something, and when you do, you don't notice that a checkbox is no longer selected, or it's changed the country back to the default of USA and therefore you haven't entered a valid zipcode. I strongly urge you to think about giving the user all the things that are wrong with his form, WITH the form below it with all the previous entries already filled out, so they only have to correct the errors and they can proceed.  It's much better that way.  You'll have less user rage. Please? Cheers, Michael Kear Windsor, NSW, Australia AFP Webworks.

> When you're done, can you let us know which site it is, so I'll put it on > my > list of sites never to go to?  I HATE forms that tell me somethings wrong, > I > correct that, then it says something else is wrong. As I've already told Jochem (who made the same comment, only far more tactfully) this for a SINGLE FIELD. The email field (a SINGLE FIELD) for example might: 1) Need to be populated. 2) Need to be less than 255 characters 3) Need to follow general email format. 4) Need to be checked against the database. You would NEVER want all four of these situations to be shown at once.  You want the system to validate until it finds an error then STOP (you don't check the database if there's no value for example).  You store than error, then check the other fields (which may themselves have many validations). So a single form MAY display multiple issues - but a single FIELD would only display one. You are still left with the potential for several iteration of a form.  They forget the email here, but here it's been found not to be unique. But if you still want to stay away from the sites here they are: www.depressedpres.com www.cfadvocacy.org www.firstnight.org Jim Davis, tired and cranky.

Jim, Are you Tired and Cranky in New England? > When you're done, can you let us know which site it is, so I'll put it on > my > list of sites never to go to?  I HATE forms that tell me somethings wrong, > I > correct that, then it says something else is wrong. As I've already told Jochem (who made the same comment, only far more tactfully) this for a SINGLE FIELD. The email field (a SINGLE FIELD) for example might: 1) Need to be populated. 2) Need to be less than 255 characters 3) Need to follow general email format. 4) Need to be checked against the database. You would NEVER want all four of these situations to be shown at once.  You want the system to validate until it finds an error then STOP (you don't check the database if there's no value for example).  You store than error, then check the other fields (which may themselves have many validations). So a single form MAY display multiple issues - but a single FIELD would only display one. You are still left with the potential for several iteration of a form.  They forget the email here, but here it's been found not to be unique. But if you still want to stay away from the sites here they are: www.depressedpres.com www.cfadvocacy.org www.firstnight.org Jim Davis, tired and cranky.

Yup. ----- Excess quoted text cut - see Original Post for more -----

Well it'll be a wonderful day, and make my tired old mother smile with satisfaction if the day ever comes when someone says I'm tactful. Bluntness and forthfightness are what I'm well known for and it's made me lots of trouble over the years, but it does save a lot of time.  I still got my point across didn't I, even if it doesn't apply to this specific field. No offence intended. Cheers, Michael Kear Windsor, NSW, Australia AFP Webworks. > When you're done, can you let us know which site it is, so I'll put it on > my > list of sites never to go to?  I HATE forms that tell me somethings wrong, > I > correct that, then it says something else is wrong. As I've already told Jochem (who made the same comment, only far more tactfully) this for a SINGLE FIELD. The email field (a SINGLE FIELD) for example might: 1) Need to be populated. 2) Need to be less than 255 characters 3) Need to follow general email format. 4) Need to be checked against the database. You would NEVER want all four of these situations to be shown at once.  You want the system to validate until it finds an error then STOP (you don't check the database if there's no value for example).  You store than error, then check the other fields (which may themselves have many validations). So a single form MAY display multiple issues - but a single FIELD would only display one. You are still left with the potential for several iteration of a form.  They forget the email here, but here it's been found not to be unique. But if you still want to stay away from the sites here they are: www.depressedpres.com www.cfadvocacy.org www.firstnight.org Jim Davis, tired and cranky.

> Bluntness and forthfightness are what I'm well known for and it's made me > lots of trouble over the years, but it does save a lot of time.  I still > got > my point across didn't I, even if it doesn't apply to this specific field. I'm pretty sure that getting a point across that has nothing to do with the topic at hand isn't something to be particularly proud of. > No offence intended. None taken.  How could I when you were actually unable to say anything about the topic at hand? This wasn't actually blunt, forthright or tactless - it was Tourette Syndrome. Jim Davis, still tired and cranky.

Jim, I think you are due for a couple of days off.  GO home.  Get a beverage, sit in front of the TV and veg for a couple of days. Or go water skiing or hang gliding or bungee jumping. But I think you're due a couple of days away from the keyboard. I know **I'd** like it if you did. Cheers, Michael Kear Windsor, NSW, Australia AFP Webworks. > Bluntness and forthfightness are what I'm well known for and it's made me > lots of trouble over the years, but it does save a lot of time.  I still > got > my point across didn't I, even if it doesn't apply to this specific field. I'm pretty sure that getting a point across that has nothing to do with the topic at hand isn't something to be particularly proud of. > No offence intended. None taken.  How could I when you were actually unable to say anything about the topic at hand? This wasn't actually blunt, forthright or tactless - it was Tourette Syndrome. Jim Davis, still tired and cranky.

Sure, but that's why you loop over the validation types as well. something like... valStruct.email = listToArray("null,maxlength,email"); valStruct.email.value = "me@here.com"; valid = true; while(valid) {   valid = true;   for(i = 1; i LT arrayLen(valStruct.email), i = i + 1) {     switch(vType[i]) {       case "null":         valid = isNull(valStruct.email.value);         if (NOT valid)            break;       case "maxlength":         valid = checkLength(valStruct.email.value);         if (NOT valid)            break;         etc...     }     if (NOT valid)       break;   } } This is very generally the best form validation routine I've been able to come up with in CF, at least until the form collection becomes an object itself. Of course if you are not on MX...you can't do cfquery's in UDF's, so perhaps the best angle would be to have each validation type a custom tag... Wouldn't it be cool though if we could have a loop watched a particular variable/method for an event? Like if a particular variable changed...the event is fired which breaks the loop immediately. -- mailto:jonhall@ozline.net Friday, June 27, 2003, 7:43:54 PM, you wrote: JD> That's only checked (as far as I understand it) before each iteration, not JD> throughout the processing. JD> In other words setting "theform" equal to "invalid" will not stop processing JD> immediately - it will finish out the rest of the code in the loop THEN stop. JD> Jim Davis ----- Excess quoted text cut - see Original Post for more ----- JD>

That's a really clever idea.  I'm a FB guy so I never really been in that situation (and I usually prefer to generate all error message not just the first), but if that's what you're looking for, I'd say it's a perfect solution. Here's a different take on the same idea, except using the same template as both the form and the validation custom tag.  Obviously have to flesh it out, but it'll let you have both your custom tag and your consolidated code all in one. ------------------------------------------------------------------------ <cfif isDefined("thistag")>   <!--- validation --->   <cfif len(form.email) EQ 0>     <cfexit method="exittag" />   <cfelseif ... >     ...   </cfif> <cfelse>   <!--- form --->   <cfif isDefined("form.myFirstField")>     <cfmodule template="#getFileFromPath(getCurrentTemplatePath())#" />   </cfif>   <form ...>     ...   </form> </cfif> ------------------------------------------------------------------------ --- Barney Boisvert, Senior Development Engineer AudienceCentral bboisvert@audiencecentral.com voice : 360.756.8080 x12 fax   : 360.647.5351 www.audiencecentral.com ----- Excess quoted text cut - see Original Post for more -----

Jim Davis wrote: ----- Excess quoted text cut - see Original Post for more ----- I think checking all the input and then displaying all the errors at once provides a much better user experience. Jochem

----- Excess quoted text cut - see Original Post for more ----- This is more for multiple validations on a single field.  So, for example, if there's no email address entered I don't want to go though the process of checking to see if it's in the DB. I could do this with a lot of CFIF logic, but I was looking for a way to bail out totally ignoring further checks (for the same field). Jim Davis