Re: [ACFUG Discuss] validating credit card numbers with CF

[Frank Moorman]

I definitely agree with Steve. Once bitten, twice shy. I enjoy the things that CF does for me on the server side, but I use my own _javascript_ and Ajax on the client side. One of the reasons is the form validation I mentioned earlier, but the other is that I was starting with Ajax before CF8 was even released. I have already created code and ways to do things that work. I am sure that everyone will agree that it is not wise to fix code that is not broken. Going forward, I still do not plan on using CF's ajax or even CFFORM. In my mind it is easier to keep consistency in the code base and do everything the same way across different pages. Unless there is a compelling reason to justify spending the time to use a new way. Once you have the logic and common _javascript_ libraries in place, it is really just as easy to "roll your own" code as it is to use CF's implementation. I admit that I did not know of the new form features for "submitonce" or "datefield" that Charlie mentioned, but I have already solved these issues in my own custom code. I agree with Steve's reasoning and while I am a supporter of CF, by using my own work on the front-end, it will make it easier for me to change the back end if I ever have the need or requirement. (For the record, I also believe in avoiding any proprietary SQL commands to always keep porting options open.) Now I do agree with Charlie in that the client side features of CF are very useful and they also have the huge benefit of making it quicker and easier to develop and roll out new applications. But in my mind the big issue is where you want to spend your time debugging? _javascript_ can be a huge pain to debug, but it is better than being forced to find a workaround or wait until Adobe patches a problem in CF. (I believe that CF is well tested, but errors do occur and when the big ones happen, managers do not like being told it can't be fixed...) --Frank On 03/11/2010 04:10 PM, Steve Ross wrote: The inherent problem with using any framework that has been distributed with/embedded in CF is that there is no upgrade path for the embedded framework unless Adobe decides to release a patch.  So when you find that bug or your designer asks you to implement their great customization to that <cfmenu> you will have to hack at to get it to work (and deal with deploying your hacks) OR like me you just decide it isn't worth it and it would be a lot easier if you just roll your own solution (or in my case choose something like jQuery that has a TON of community support). Speaking more about the built in validators, they work fine when you ONLY use them and them alone. If you need to validate some custom js code and then let CF's validators fire at the same time you will have issues. Or you will end up ditching CF's because you wan't to control how you notify the user etc. Also I just found a bug in cf8 where cfajaxproxy is doing some weird re-writeing of my cfc path. Again, more ammunition as to why I don't like the built in because there is a point on a large project where you will get to a place where it causes more headaches than fixes them.  These may sound like edge cases but, again I'm just saying why *I* stay away from the built in cfform, cfajax, cfmenu (display/framework) oriented tags. -Steve On Thu, Mar 11, 2010 at 3:27 PM, Charlie Arehart <char...@carehart.org> wrote: See. :-) With all due respect and admiration, Steve, that’s just the sort of attitude I’m railing against. I think it’s just dead wrong to flatly reject the tag outright, suggesting that it should NEVER be used. :-) Again, I get that for SOME people and for SOME situations, there may be reasons that it doesn’t work for you. Goodness, that’s true with just about anything, right? But before accepting that bold dismissal, I hope that some who’ve heard only that sort of ill regard for it will take a look at the article I pointed out below, where I highlighted a few ways that CFFORM and its subsidiary tags have evolved fairly significantly over the years.  Some of them are quite valuable, such as the “submitonce” validation that was added to help prevent users from hitting submit twice on a form, or the cfinput type=”datefield” which offers a very useful popup calendar. Granted, many have the chops and motivation to craft such features by hand or may choose to use scripts (or entire libraries) they get from elsewhere, and there’s no denying that becoming versed in a new ajax library can bring still more value in features that perhaps Adobe hasn’t yet implemented. But my whole point is that for a great majority of users, having the feature built-in without any need for coding is simply a valuable asset that shouldn’t be dismissed so readily and completely. Again, I’d recommend people take in the various perspectives but give caution to outright dismissals. That just isn’t due diligence. But hey, mine is indeed just one person’s opinion. I don’t expect it to carry any more weight than others. /charlie PS Here’s the PDF url again: CFFORM: Are You Sure You Want to Ignore It? http://www.carehart.org/articles/#2007_3   From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Steve Ross Sent: Thursday, March 11, 2010 1:42 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] validating credit card numbers with CF   Well the problem with CFFORM is that it will burn you.  I have stopped using it as a result. It is easier to know what is going to happen when there isn't some blackbox trying to do whatever you think you want for you. This is especially the case with all the built in ajax stuff. Do yourself a favor and NEVER use it unless you you are doing some one off ad hoc page that will be thrown away. However, we all know how rarely that happens and typically you will come back to it and have to rewrite when some bug hits later on down the line.   Ok I'll stop ranting... back to flex. On Thu, Mar 11, 2010 at 12:01 PM, Charlie Arehart <char...@carehart.org> wrote: About Frank’s situation of having been burned in the past by CFFORM, it kind of makes my point. It’s this kind of situation, where someone gets burned and the issue is later fixed, where sadly so often the “bad taste” is left and people “move on”. Worse, at least in your case you know the problem was fixed, but others may have seen people report the issue but never heard of MM’s solution to it, so they go on bad-mouthing the tool. <snip> ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink ------------------------------------------------------------- -- Steve Ross web application & interface developer http://blog.stevensross.com [mobile] (912) 344-8113 [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ] ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------