ColdFusion 9 Feature Request: Drop Ajax/JS libraries
ColdFusion , Development , YUI , JavaScript Add commentsYes, I said it. Going forward I do not think that Adobe should waste time on implementing JS Code libraries. Ext, YUI and others exist so you can easily integrate them into your code already. In the last few months alone I believe there have been 2 or 3 version upgrades alone of the Yahoo YUI tool and a 1 major version upgrade for Ext.
If you want to have an AJAX driven drop down, write it yourself or download a custom tag, or better yet; write the custom tag yourself and distribute it freely. I would much rather see the time spent by engineers working on ColdFusion spent working on the server side portion of ColdFusion vs. doing these seemingly 'cool' integrations. Don't custom tags exist for this purpose alone? Why build it into a server side product?
I'm tired of seeing posts and emails and requests to implement further feature sets, upgrade versions or change libraries all together. ColdFusion does not need to be my meeting ground of technology. If you had spent 2 more minutes writing your code you could have implemented the Ext library yourself, probably done a better job and you won't be beholden to a server side technology for your client side code...
Flame on
May 13, 2008 at 4:35 PM Hi Russell I am 200% agree with you, I was thinking about this stuff, even 8.0.1 is not that cool for ajax stuff. Adobe should offer better tools ...... might be complete integration of hibernate, video, audio capabilities etc
May 13, 2008 at 4:36 PM ah, finally! seriously, what's next, CF writing bloat HTML for me so i don't have to design my own websites? i learned ExtJS pretty quickly and that's what you will have to do if you want to get any real power out of the Grid, Tree, or other components. i can only agree, focus on the server side, like the performance boost and cfimage tag in CF8.
May 13, 2008 at 6:00 PM I completely disagree. In this case you could nix a whole lot of CF tags simply due to the fact that you could just write the Java code yourself. Just as with the underlying Java, CF makes it easy to build a web app by wrapping the Java functionality into simple to use tags. That's the heart of CF. Consider this: cflayout type=\"tabs\" cflayoutarea title=\"MyTab\" source=\"includes/somefile.cfm\" /cflayout Now, in Ext you'd have to write this: // second tabs built from JS var tabs2 = new Ext.TabPanel({ renderTo: document.body, activeTab: 0, width:600, height:250, plain:true, defaults:{autoScroll: true}, items:[{ title: My Tab', autoLoad:'includes/somefile.cfm' }] }); You don't like the Ajax stuff...don't use it. Very simple fix to the issue. Remember, not everyone \"gets\" JS just like not everyone understands communicating with LDAP, sending email, manipulating images, etc with Java. [/flame] :-) (btw, I can't see the submit button for the comments and the \"Remember my information\" is partially cut off by the blue footer bg. just an fyi.)
May 13, 2008 at 6:01 PM My comment looks crappy without line breaks. What up wit' dat?
May 13, 2008 at 6:08 PM @John: When I get a chance I'll fix your comments, not sur whats up. Yep I would nix all of them. CFForm, CFInput, CFLayout. Sure they are great, but I also feel like too much focus has been taken away from server side features in lou of these cool client side features. Let some 3rd party company build these as custom tags and sell them or give them out for free... I'm more afraid of ColdFusion loosing focus and trying to take on too much. Why blur all the lines, let some products stand on their own...
May 13, 2008 at 6:29 PM Ok...now I would agree with you regarding them taking precedence over server stuff. I wouldn't nix'em or send'em to a 3rd party but I agree they shouldn't be in the top 10 of to do's for cf9.
May 13, 2008 at 8:19 PM Port them to customtags and Open Source them, or if CF is extensible like OpenBD just opensource those Java classes. Things like cfajaxproxy are nice but cfgrid and tree I think those are the types of things that should be community driven and open source.
May 13, 2008 at 10:37 PM I guessed you missed the announcement at cf.Objective() regarding Adobe's partnership with ExtJS. So, in short. No. It's not going to be dropped and Centaur has a lot of new Ajax features in the works. I recommend you take John's advice and just not use them if they don't meet your needs. This is specifically why
May 13, 2008 at 11:36 PM I take no issues with not using them, and that's not the point. It's more about effective use of the ColdFusion Dev team. I'd rather have them spend more hours working on making the ColdFusion Server faster, fixing bugs and expanding the server side functionality. I can't fix Adobe's CFThread to work the way I think it should (easily), but I could certainly write my own CFContainer tag...
May 13, 2008 at 11:38 PM @Adam (ok that feels odd) I brought up the ExtJs announcement else where (maybe in my share comment on google reader). I get Adobe's value add here but it is frustrating with Yui's (or other library) release iterations being much shorter than Adobe's. I'm assuming (ney hoping) the new deal with ExtJS will probably mitigate the lag a bit thought?!? Since its not going away I hope Adobe has 1) a lot of focus groups smoothing out easy use with a big target on easier customizations 2) Is employing usability experts that can validate that the default behavior of the ajax controls are indeed usable. I can say with experience our UI guy (used to be with IBM) is not a big fan of CF8s outpoop, some to do with CF8 some to do with ExtJs's behaviors.
May 14, 2008 at 2:57 AM there are already multiple extensions for ExtJS (2.0) support, so the point is that the CF team shouldn't waste time on implementing a library that is updated and changed every few weeks and concentrate on improving the server-side architecture, like cfdocument, because it still can't produce PDFs that look the same as in the browser. and i agree, drop cfform, cflayout, etc., it's all just bloatware...
May 14, 2008 at 8:24 AM My problem with this is that most of the AJAX libraries try to stick to the KISS principle. Why should CF try to make it even easier? At some point, you have to, as a server platform, stop trying to hold developer's hands and let them use what's out there on their own. Flash Forms was an attempt to do the same thing with Flex, and you see where that ended up. It might as well be deprecated at this point. Why do I have the feeling that the CF AJAX stuff will go the same direction?
May 14, 2008 at 11:03 AM I don't agree with this. Even though I ripped out a lot of the Adobe Ajax stuff from http://www.coldfusionbloggers.org, I only was able to do so because I've gotten more familiar with Ajax. The ease of use is far more important then I think most people realize. Those of who blog, and read blogs, are the upper crust compared to most of the CF developers out there. I'll also add one more point. Adobe's Ajax support isn't just UI stuff, but plumbing as well. I still say that cfajaxproxy is one of the most important features ever added to CF. Being able to use my CFCs via JS with one simple tag is incredible.
May 14, 2008 at 11:09 AM I wouldn't put cfajaxproxy and cfform in the same context. I believe that holds that special in between ground, both are very different IMO. Your right though, it is often some times too easy for us to forget the newer developers and how one of ColdFusion's biggest pluses (and sometimes negatives) is how easy it is to use and learn and the immediate power it gives an FNG.
May 14, 2008 at 11:27 AM Andrew, you're right about Flash Forms but wrong about the Ajax stuff. As Ray pointed out, cfajaxproxy rocks hard! Again...CF makes things easy so we, as CF developers, can easily get things done. It isn't about \"how easy [your favorite JS library] is to use\" but how CF can help you get from 0 to 60 REALLY fast. Look at my first comment regarding the cf tabs. (thanks for fixing my comment Russell) Still...don't like it...don't use it. It isn't forced upon you nor is, to my knowledge, the CF team putting Ajax stuff before more important server work. Based on that last statement this is a non-issue, according to the original post.
Jun 10, 2008 at 1:30 PM I've always rolled my own AJAX widgets because the ones built into ColdFusion have never been very good... at least not in my opinion... and I wouldn't expect them to be because it's a one-off thing for the ColdFusion team -- it's not their top priority, it's just something they do as a bell/whistle at the end of the day. There was a lot of fanfare about the updates to CFFORM in version 7(?) and I remember hearing the team lead (I'm not remembering his name right now) talking in a presentation about how they'd wanted to update CFFORM for a long time to make it faster and better, but they couldn't get to it because they never had the time. Because - as it should be - it's not a priority for them. The one thing that really came out of that was XML forms (and possibly Flash forms although I don't use them). I don't use CFFORM still because even the XML forms implementation wasn't as flexible as I wanted. But I'd be plenty happy to have them not only stop working on javascript features, but for that matter remove CFWINDOW. They won't for obvious reasons, but CFWINDOW has just unleashed a hideous evil on the world because people use it indiscriminately, not remembering that people stopped using popup windows left and right in the first place because users were complaining about their indiscriminate use. CFWINDOW just takes us straight back to those good old days of pages cluttered with popups -- with new and improved popups that have more bugs in them like they don't play nice with Flash. I'd much rather see carefully considered and well implemented AJAX.
Jun 10, 2008 at 1:32 PM I agree with Ray about cfajaxproxy though.
Jun 10, 2008 at 7:19 PM @Ike There isn't a single feature that is treated as a one-off bells/whistle. Adobe has updated CFFORM with every release. Back in the CF5 days it generated some nasty HTML. CF7 specifically did a bunch to clean up the html, so whomever told you that it's wasn't worked on was flat wrong. CF8 also updated CFFORM as CFGRID and CFTREE are part of that. Yes, Flash Forms have pretty much been deprecated. At the time Flash Forms were added to CF, Flex was a server product that cost $20,000US. Now Flex is open source and the Builder is around $250US. Flex is recommended solution for flash forms. Exactly what wasn't flexible enough about xml forms? Maybe we can fix it for you in CF9? I understand that many people like to roll their own, but understand those people are in the vast minority. Writing cross browser AJAX is a pain in the arse and most people prefer to spend thier time solving problems that haven't already been solved. In fact, Adobe's not the only one who understands this need as OpenBD just announced their intent to support Google Web Toolkit. At cf.Objective() 2008, Adobe announced a commercial partnership with ExtJS and their intent to overhaul the AJAX widgets in CF8. As far as CFWINDOW goes, that a personal opinion. I find it very handy when creating Master/Detail style applications. To say that we unleashed a hideous evil is a bit over dramatic.
Aug 6, 2008 at 6:33 PM I take this opinion. I myself do not use flash forms, the reason is I know Flex. For those new CF developers who are not seasoned programmers, these features are a huge selling point. It gets them excited because they can look like a hero to their boss and its easy to do. They don’t care about memory monitors, 64bit support, or faster CFC creation times. ColdFusion has huge selling points no matter if you are a novice or expert. If those features help drive sales, good because that's what pays for the engineering team salary and product marketing costs. -Brian
Aug 7, 2008 at 10:07 AM Life is demanding and there is no need to make even more demanding. I use Joomla because it has all kinds of applications, extensions and components just ready to be used. That's why I use Coldfusion for the stuff that I just can't buy OTC. Because I can write and develop in it very fast. The faster I turn over those projects the more money I make. Why do you want me to slow down and write everything my self? And lose money. I pay for CF because it has all these tags, without them CF becomes useless and I might as well use .Net.
Aug 10, 2008 at 12:50 PM Hmm... I find myself wishing for a better way of managing connectivity to blogs... I just today installed an RSS reader for the first time in a few years because I wanted to start actually following blogs and realized that I somehow neglected to subscribe tot his entry... So now here I am really wanting a system that would allow me to not only subscribe to the rss feed, but mark specific entries (particularly those I've commented) and see comments on those as they're added in the same rss interface... I doubt anyone's found a solution for that yet. And probably won't for a long time to come... ::sigh:: Anyway... Apologies to Adam for not responding sooner and for possibly appearing antagonistic... that's not my intent... I love CF -- it's the only platform I've wanted to work with since I got started with it in '97 and for the most part I've really not worked with other platforms. I worked for a year in ASP in '99 because someone offered me the job and hated it. And I just recently dabbled a bit in PHP and find it similarly frustrating (like trying to carve an ice-sculpture with a bag of rusty nails). Honestly, I adore ColdFusion, I always have... just none of the client-side features. I recently published an article in which I ported Ray Camden's Galleon forums to several frameworks and then compared those frameworks, showing mostly how knowing any one framework leads to a general understanding of frameworks that can be broadly applied and so is a plus for any developer... You can download that here http://ontap.riaforge.org/enclosures/galleon%2Ezip That particular article includes a couple of sub-articles where different subjects are explored, one of which is the fact that \"server-side\" form validation in CF8 is not \"server side validation\" and is not secure, leading to a false sense of security for anyone who chooses to use it. That sub-article also includes a step-by-step tutorial on how to bypass the server-side form validation in CF8 (which is now easier than in previous versions). By comparison the onTap framework's form tools provide actual server-side form validation. Though I think it would actually be somewhat unfair of me to expect a similar implementation from Adobe because it would (imo) break from the server's traditional approach to syntax. CFForm's server-side validation would become much more like cfthread / cfjoin syntax. I dunno... maybe the engineering team will actually like that idea... after all, it is just my opinion that it breaks from tradition. The onTap framework forms also give me the ability to add arbitrary namespaced xml elements and attributes to various elements within the form to add features that as far as I know I can't add with cfform.
Aug 10, 2008 at 1:04 PM @Marwan -- Oh I don't want you to slow down by any stretch of the imagination... I'd like to make CF development evern *FASTER*... Thing is, I think that can be achieved by adding more manpower/mindpower to the solution -- not just CF, but CF + Framework ... like CFonWheels, Transfer, etc. I'm obviously biased to the onTap framework because it's the one I developed (and DataFaucet now), but the reality imo is that using CF with any full-stack framework (or combination of niche frameworks) can be way faster and easier than using CF by itself... I think leveraging the support of the wider community and not just the CF engineering team is the way to go. The CF engineering team are a bunch of great, smart guys. They know they're stuff, they're great at their jobs and they do an awesome job bringing us new versions of the CF server. However -- it's a small team, compared to the broader community that includes folks like Gert Franz and the Railo team, the Fusebox team, Sean Corfield, etc. etc. For what its worth, my comments about the CF team not working on certain client-side techs anymore are really not about not liking the team or what they do, they're about the idea of people focusing on doing a fantastic job filling a small niche and then working with a group of folks who also do a fantastic job filling other small niches, rather than having everyone try to be everything to everyone else and end up filling many of those niches poorly because we're all spread thin. But that is just my opinion. And ironically... as I'm making these comments about not enjoying the form features in CF, just a couple days ago I was listening to the CFConversations podcast and hearing about Sean Corfield stepping down from the FuseBox team and the new guy taking over (Adam Haskel? -- I don't remember for certain) saying that 2 years ago he stood in front of his boss and gave a list of reasons why they should not use FuseBox. And now he's heading up the FB team... and even before that, Sean himself had always been very non-plussed by the Fusebox framework and then he had taken over the team. So ... I'm hoping that perhaps my comments can be taken in a similar light. I'd like to work together perhaps not just in spite of having differences of opinion, but actually because we have differences of opinion. :)
Aug 10, 2008 at 1:15 PM Arbitrary input types... something else I forgot... one of the recent versions (6?) when they overhauled cfform and added xml forms, they added cftextarea and and hidden, submit and button types... Well, that's great... but one of the things I can do with the onTap forms is have plugins that add arbitrary input types. The Members onTap plugin for example adds which creates a specific ajax-enabled multi-related select element. Is that something that could be added in cfform? Possibly... but lord only knows what the implementation details would be like...
Aug 10, 2008 at 3:39 PM argh... I didn't realize that this blog doesn't properly escape comments... so... not sure, but it looks like I could use this to execute an XSS attack... I won't try, 'cause that's not my thing... just sayin'... but it also means it chewed up 2 of my examples because they didn't get escaped... so where there are input elements in my comments above it should read <tap:required><input ... /><input ... /></tap:required> and <input type=\"region\" /> ... and <cfinput type=\"path.to.my.cfc\" /> didn't show up at all... confusing to read I'm sure.
Sep 19, 2008 at 9:12 PM We have 2 CF Standard servers. Cost of CF $2600. Cost of putting EXTjs on the workstations of our 6 developers: $4,999. With support that comes out to $7,129. Just what the heck are you talking about? Are you using it without paying? Heck yes I want it built into CF and I want more of it.
Mar 18, 2009 at 6:16 PM late to the conversation, I know... but I have to wonder -- when did you start working with coldfusion? I'm guessing not before MX. The language became successful in the first place *because* of the sorts of things you want to rip out of it. It's incredibly easy to learn the basics and accomplish the majority of tasks without having to learn any kind of scripting. In CF3, that was cfform taking care of your validation for you. In CF8, it's things like ajax. if you don't like CF's implementation of it, great... you can write it yourself, or write a custom tag and sell or release it. But why limit Adobe? They're not forcing you to use their tools -- just making them available in an easy to use format.
Mar 18, 2009 at 6:27 PM @jc: Not really sure who your addressing but I've considered my self a ColdFusion developer since about March of 1998.
BTW, CFFORM is and always has been complete garbage. No one should ever use it no matter what there level of developer skill is!