BTW, We're skipping Web 3.0, and going straight to Web 4.0, where all this will be rendered moot by HTML. Aren't you happy? I guess all this academic talk of dead languages (who needs Adobe? Flex/Flash/FP? CF? SQL? ha!!!) iPhone, iPad don't support it 'cause Adobe engineers are hacks.............etc...
Unfortunately there are giants out there who are making big steps (mostly bug muddy footprints). MS has their ideas, Apple has there's, the W3C can find it's own ass without a map. For those of us tucked into our corner, I can only hope that the growing pains to come aren't pains we've already been through. On Thu, Mar 11, 2010 at 5:44 PM, Charlie Arehart <char...@carehart.org>wrote: > Sure, and again you make a reasonable case for the kind of person who > will prefer to stay away from them. No question. > > And avoiding proprietary SQL is another one of those topics where I hope > reasonable people can disagree. :-) It need not be a dogmatic stance in > either direction, just more pros and cons to be carefully weighed. > > As for risks of needing to debug the JS of CF’s tags, again, I’ll just > stand up as one who would say that’s never even been an issue for me. But no > doubt there are circumstances where it could be for some. Just more thought > for the debate if one ever considers it. > > Hope this discussion has been useful to some. We now return you to your > regularly scheduled programming. :-) > > > > /charlie > > > > *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Frank > Moorman > *Sent:* Thursday, March 11, 2010 6:01 PM > > *To:* discussion@acfug.org > *Subject:* Re: [ACFUG Discuss] validating credit card numbers with CF > > > > 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 > > > > ------------------------------------------------------------- > 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> > ------------------------------------------------------------- > -- Darin Kohles RIA Developer
