Fair enough, but I'll simply toss my hat into the ring with people who would say, "yeah, but I've never bothered with customizations that ran into a conflict with the built-in libraries".
So do you see that it's one thing to say "never use them", and quite another to add the caveat of why it's not worked for you. Then people can make a reasonable decision. But so many people-and respected people who others would listen to-will just dismiss something out right, and many follow thinking, "well, if it's not good enough for them, it's not good enough for me". Sadly, often it is not only "good enough" but far "better than nothing". Still, again, I get why those who DO use such customization will favor using a library directly. Then again, as for the custom validation collision issues, didn't you say something was resolved by MM? Sounds like you're saying there are still issues. As how to "control how you notify the user", I would note that this seems to be provided for by, for instance, the onerror attribute of CFINPUT. Even so, as for trying to do both built-in and custom validations, I see that while there is an OnValidate on CFINPUT to let you name a custom validation routine, it says if used then the VALIDATE attribute is ignored, so that part certainly points to some of the inflexibility you refer to. Again, I'm not saying they're perfect, nor that some don't have good cause to prefer to avoid them. I'm just suggesting that people take in all the pros and cons-and don't assume that those arguing for CFFORM and its kin are necessarily ignorant for having the temerity to stand up in favor of them. :-) /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Steve Ross Sent: Thursday, March 11, 2010 4:10 PM To: [email protected] Subject: Re: [ACFUG Discuss] validating credit card numbers with CF 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 ------------------------------------------------------------- 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 -------------------------------------------------------------
