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 <[email protected]>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. > > And I say this as much about many CF features and tools out there. > > How many hold the report builder in ill esteem, though it went through many > revisions, bug fixes, and improvements in 7.01, 7.02, and 8, yet many never > gave it a second chance. > > Same too with the CF 8 Server Monitor. I hear so many say “it’s a resource > pig”, when that’s a patently irresponsible assertion, if it’s not clarified. > There is one feature of the monitor, “start memory tracking”, which can be a > pig (and isn’t for everyone). But if you don’t enable it, then the server > monitor is of little impact at all. And indeed, you can leave off all 3 > start buttons and it STILL provides value with zero “cost”. > > Some will have heard these cries from me before, including these blog > entries/articles where I elaborate on each of the above: > > Have there been any updates to the CF Report Builder feature? Yes, in fact > > http://www.carehart.org/blog/client/index.cfm/2008/12/13/cf_report_builder_updates > > CF 8 Hidden Gem: Incredible Info from the Server Monitor, with Zero > Overhead > > http://www.carehart.org/blog/client/index.cfm/2007/6/15/cf8_hiddengem_monitoring_incredibleinfo > > > as well as a FAQU “tipical charlie” column I did (available as a PDF > extract): > > CFFORM: Are You Sure You Want to Ignore It? > http://www.carehart.org/articles/#2007_3 > > I could go discuss others. I simply want to make the case that sometimes > old “bad news” isn’t any longer as “bad” as it was earlier. :-) We would all > do well to consider if some argument against something is truly valid (and > if perhaps the assertion is with respect to something that may have been > fixed/enhanced since then.) Thanks for offering a great demonstration of > that point, Frank. Though I’ll understand if you’re “once bitten, twice > shy”, regardless. :-) > > /charlie > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Frank > Moorman > *Sent:* Wednesday, March 10, 2010 2:42 PM > > *To:* [email protected] > *Subject:* Re: [ACFUG Discuss] validating credit card numbers with CF > > > > I used to use CFFORM with CFINPUT until I got burned by ColdFusion 7. When > CF7 was first released we upgraded. > > One or two weeks before our implementation, we found out that their was a > major bug (i.e. one that affected many pages in our apps) If you used both > CFINPUT's validation routine and added your own custom javascript validation > (for business logic that CF wouldn't handle) only one would execute (I > forget which one.) We had to scramble for a workaround. We did create a > javascript solution (Something like onSubmit="return(CustomRoutine || > cf_Checkthis(this.name));" ) but then we needed to apply it to 200 or 300 > forms throughout our applications. > > One or two months later Macromedia fixed the problem, but by then we > already started moving to use our own javascript exclusively and when you > have a common js include, it really is not that difficult to avoid > CFFORM/CFINPUT. > > Frank > > On 03/10/2010 02:14 PM, Charlie Arehart wrote: > > Yep, Shawn, but I realize this is a subject about which some are passionate > (and I don’t mean Dean, who has rightfully earned his place in the security > pantheon), but I mean others who may have heard bad things about CFFORM > (whether they really ever affirmed any issues) and would want to warn others > or claim that my suggestion was naïve and leading lambs to slaughter. :-) > > I’ve seen it so often over the years, that I just didn’t want to have them > kick the door in to make their point but rather just open the door so they > could make their point without any violence. :-) > > > > /charlie > > > > ------------------------------------------------------------- > 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 <http://www.fusionlink.com> > ------------------------------------------------------------- > -- Steve Ross web application & interface developer http://blog.stevensross.com [mobile] (912) 344-8113 [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]
