coldfusionJedi

This entry was posted on Sunday, July 2, 2006 at 2:58 PM. It was filed in the following categories: ColdFusion. It has been viewed 6,000 times and has 46 comments. Download attached file.

TweetBacks

Comments

[Add Comment] [Subscribe to Comments]

• Comment 1 written by Emmet on 2 July 2006, at 3:42 PM

  

  Did you put this up for download somewhere?

• Comment 2 written by Raymond Camden on 2 July 2006, at 4:26 PM

  

  Um, yeah, the Download link. ;) I -do- need ot make it more obvious.

• Comment 3 written by Kyle Hayes on 2 July 2006, at 4:29 PM

  

  When there is a download, I think that it should be before the comments link or immediately after and perhaps have an icon.

• Comment 4 written by Lola Lee Beno on 2 July 2006, at 4:51 PM

  

  Or perhaps an arrow icon pointing to the Download link.

• Comment 5 written by emmet on 2 July 2006, at 5:04 PM

  

  I guess i never paid attention to that before.

• Comment 6 written by Simon Horwith on 2 July 2006, at 5:23 PM

  

  I assume you're keeping the XML VERY small - otherwise there'd be no reason not to simply use WDDX. Though I do think that WDDX isn't ideal for transfering data (especially large amounts of data) because of how verbose it is, I think a SPRY WDDX parser would be useful and cool for some people.

• Comment 7 written by Raymond Camden on 2 July 2006, at 6:14 PM

  

  It is as small as you want it to be. I mean, if size is an issue I'd ensure a query, for example, only had the columns you really need. The reason to not use WDDX is that not everything can parse WDDX, including Spry. While I'm working on such a thing (as was made obvious by the entry), I thought this CFC would be of use to folks for now.

• Comment 8 written by Dan Sorensen on 2 July 2006, at 7:07 PM

  

  I'm used to your download links now, but it would probably be easier to find if the download link was red when it's present. I'm not sure if that's possible with your setup.
  
  Thanks for the CFC example, makes working with SPRY a little more interesting. :-)

• Comment 9 written by Simon Horwith on 2 July 2006, at 7:35 PM

  

  It's not as small as I want it to be, assuming you have defined the XML format used to represent the data. What I did a poor job of trying to say is that the only reason I can think to create such a CFC is if you're trying to make the XML string much smaller than it would usually be if you were to represent it as WDDX.

• Comment 10 written by Raymond Camden on 2 July 2006, at 8:05 PM

  

  I think you are missing the point. Right now - Spry requires XML. Yes, XML isn't the slimmest it could be, but it is what Spry requires. I know I'm seeing pretty quick responsiveness w/ Spry up to about 500 rows, which seems rather fair. I also thought the CFC would be of interest for folks needing a generic set of "to XML" type functions, which may be used in places where network traffic isn't an issue. (What I mean is, they aren't translating it to XML for transfer, but for other reasons.)

• Comment 11 written by Simon Horwith on 2 July 2006, at 8:17 PM

  

  I agree - just thought I'd point out that there is already an easy way to represent data in XML format using CF, albeit a very verbose one. Adding a JS library to the client side would add universal support to this somewhat 'standard' XML format (which, did I mention, is very verbose?). Just wanted to point that out - I'm not saying that there's anything wrong with your CFC or with people using it.

• Comment 12 written by Raymond Camden on 2 July 2006, at 8:23 PM

  

  Heh, ok. I did mention Spry in the beginning of the entry, but ok, I see your point.
  
  Although - I compared the XML generated by my code using my simple query and converting the same thing to wddx. My XML was 415 characters. The WDDX was 611.

• Comment 13 written by Michael White on 2 July 2006, at 8:31 PM

  

  Man I cannot believe how good your timing is... I'm trying to figure out a way to convert a directory structure listing into an XML document, scratching my head... searching livedocs... and well, here it is... Thanks Ray!

• Comment 14 written by Simon Horwith on 2 July 2006, at 8:34 PM

  

  I'm not surprised - WDDX was and still is a fantastic idea, but it is ridiculously verbose. That's something you REALLY need to keep in mind if you're going to represent data as XML for the purpose of being passed between environments (databases, application servers, and the file system) - keeping that XML small is necessary and paramount if you want it to scale.

• Comment 15 written by Raymond Camden on 2 July 2006, at 8:43 PM

  

  If folks think it makes sense, I can add an arg to queryToXML for columns to ignore. This would help trim things down even more. (Although you would normally want to do that in the original query.)

• Comment 16 written by David A. on 3 July 2006, at 12:06 AM

  

  this is great... thanks Ray!

• Comment 17 written by Teddy R Payne on 3 July 2006, at 9:30 AM

  

  Yes Ray, you really need to make the download link very large. I suggest the techniques used by the firefox download page. It is huge and has pretty colors. =)
  
  As for the XML functions and component ideas, I can see an immediate use for the functions in the realm of configuration files. If you wanted to create dynamic xml config files, then easy to use functions would be a good way to speed that up in conjunction with the other XML functions provided with CF.
  
  Serialized data will always be a problem for transferring data. Flex really makes this beautiful. The flash remoting will slowly become my tranfer layer du jour. You have to love raw data.
  
  Data sushi style!!

• Comment 18 written by Neil Bailey on 3 July 2006, at 8:44 PM

  

  Ray,
  
  Loved your CFC talk (even though it turned out you are right about passing in a structure instead of individual arguments :) at CFUnited. Also, thought that your Application.CFC article in the new CF mag (can't remember the name off the top of my head) was excellent as well.
  
  That being said......
  
  In MY humble opinion, SPRY isn't ready for prime time. Its a nice little toy, but not overly sophisticated in what it can/will do, and its ability to allow the developer to modify the user experience is sorely lacking (other than its HTML table capabilities). I think you are pretty much dead-on-balls-accurate with pretty much every single thing out of your mouth, and I can't understand how you can be missing the mark THIS much with SPRY - I feel your so far out there on this one that is makes me feel that maybe I am wrong, simply because I agree with you so often (does that make sense??)
  
  I understand you're not an Adobe employee - or even associate, if I understand correctly - and its not your job to sell their products. But, if you could, explain why I should use SPRY instead of AJAXcfc, for example.
  
  Please don't misunderstand me - I am truly not attempting to rain on your SPRY parade here; I am just a touch nervous with my OWN outlook because in this instance it is completely different from your own. If you have a second, explain how SPRY competes with the 800lb gorilla in the room - in this case (again, IMHO) AJAXcfc.
  
  I appreciate it. Your blog is an excellent resource, even if it is offbase on this one :)
  
  nb

• Comment 19 written by Raymond Camden on 3 July 2006, at 8:55 PM

  

  Neil,
  
  First off - in the future - please know it is ok to disagree with me. No need to worry about offending me. ;)
  
  Spry is NOT released code yet. I would only use it on a production site if you were sure it would work well for you. But there is a reason Adobe calls it a Pre-release, because that is exactly what it is.
  
  Spry right now is super good at reading AJAX data. By that I mean, it is trivial to use Spry to bind data to a remote data source. I have yet to see a system do that as easily.
  
  It isn't just tables, but tables are used in most of the examples. I know I showed sme drop downs as well.
  
  There -are- widgets in Spry, but they haven't been heavily documented yet. Future releses will show more information about them.
  
  Does this make sense?

• Comment 20 written by Raymond Camden on 3 July 2006, at 8:55 PM

  

  Btw - I finished my code. I now have Spry talking directly to a CFC w/o the need of toXML. The code is ugly as sin though so I'm not sharing it yet.

• Comment 21 written by Neil Bailey on 3 July 2006, at 8:59 PM

  

  I apprciate your.....humility, I guess. And yes, that actually makes me feel MUCH better about your stance on Flex (because I know you stay awake at night worried about ways to make me feel better - hahaha, please tell me you can read the sarcasm there!).
  
  I am very new to the entire AJAX scene (we've been using it for the the last couple of weeks), but it just seems to me that with such an established, easy to use, flexible AJAX framework as AJAXcfc is already in the marketplace, it would behoove Adobe to work w/ Rob to make AJAXcfc perfect (hell, call it SPRY, call it whatever you want) - just that starting OVER seems.....silly.
  
  But, who am I to second guess the ways and days of Adobe? I personally think that they are also WAY off the mark with Flex2, but again, what do I know.....

• Comment 22 written by Raymond Camden on 3 July 2006, at 9:26 PM

  

  Well, you are bringing up 2 things now, Flex 2 and Spry. :) From what I know, Spry's main advantage is how easy it handles displaying the content, which to be honest is where I think we spend 99% of our time.
  
  Flex 2: Why do you not feel it rocks? I mean, I can't think of another way of making RIAs.

• Comment 23 written by Neil Bailey on 3 July 2006, at 10:17 PM

  

  I was saying this to everyone I met at CFUnited - in fact, I was saying the same thing to you, but you told me that as long as the application included/did everything you needed it to, you were able to live with it - the load time of Flex applications is - at least, to us - 100% prohibitive. I have NOT seen an application built on the final release version of Flex2, nor have I seen a Flex2 app run in the new FlashPlayer 9 (which you pointed out to me is supposed to have MUCH improved performance), but after seeing many applications built in the beta releases of Flex2, and after our own 100% nightmarish experience w/ Flash Forms (yes, I understand that they are two different things, but Flash Forms is our only frame of reference for a real-world app), Flex2 is going to be a VERY hard sell to us. I am sure I will end up playing with it, but (and I asked the same question on Ben Forta's blog) I can not think of a single real-world app that would be built in Flex - other than a really cool dashboard.
  
  Yes you can build a really cool storefront in Flex - but you wouldn't....again, the load time would come into play and your customers would be gone. You could build all kinds of really cool things in Flex - but, the bottom line is, other than geeks like myself seeing what I can do simply to see if I can do it, I truly don't see Flex (or the other products like it - read Lazslo) making much of an impact - the overhead is truly just too great. Its like this really cool concept car that everyone flocks to a car show to see, but would NEVER buy for their daily commute to work.
  
  What else would you use to build an RIA? Well, its funny you ask that, because after we rewrote almost all of our apps in Flash Forms (curteousy of the lobbying of yours truly - MAJOR mistake), we asked ourself the exact same question. What we came up w/ is straight DHTML using an AJAX connector (AJAXcfc in our case) to connect to the backend.
  
  If I seem to be pushing AJAXcfc hard, I don't mean to - I swear I have no connection w/ Rob Ghonda at ALL (never met him before last Wednesday). AJAXcfc just really, REALLY saved my bacon by providing a reasonable alternative to the Flash Forms. Does AJAX provide the same built in validation that the Flash Forms do? No, of course not. But the apps now load in 3-5 seconds, instead of the 45-50 seconds they were taking to load before, and to my boss, that is more important than built-in validation - which we can write routines to replicate anyway.
  
  Sorry for the extra-long response.
  
  nb

• Comment 24 written by Simon Horwith on 3 July 2006, at 10:26 PM

  

  There's a lot to comment on there and I'll let Ray continue his dialogue, but I did want to chime in and state for the record that I'm pretty confident that you wouldn't find that the load times in Flex 2 are prohibitive what-so-ever. Flex 2 apps tend to load extremely fast... and if it doesn't, it's usually the developer's fault and can be fixed. Just my observation and experience.

• Comment 25 written by Neil Bailey on 3 July 2006, at 10:36 PM

  

  hahahaha was that a polite way of calling me a moron?? Its ok - maybe I AM an idiot (my ex-wife has certainly called me worse :). I did point out that I haven't even SEEN an app built w/ the final release of Flex2, and I haven't BUILT anything with Flex2 at all - final release or beta.
  
  I have, however, built a large number of flash forms, which use remoting to connect to a CFC on the back end (ala ASFusion). And as I said in my last post, this is my only frame of reference for a real-world app (I understand that they are two different things, but I believe that Flash Forms are a sub-set of Flex, no??) And I can't see a single thing we would EVER use Flash Forms for again. They look slick, and the validation is fantastic, etc etc etc.
  
  But I can get the same (well, a comparable, anyway) slick set of UI widgets from DOJO, and can duplicate the remoting functionality w/ AJAX. And the form loads in single digit seconds - usually under 5. When Flex can deliver an app in under 5 seconds, then maybe it has real world usage.
  
  All of that being said, not a single person has been able to tell me what they would build in Flex for a real-world, paying project (hell, I asked Ben himself personally that exact same question at CFUnited, and he - perhaps unintentionally - completely sidestepped the question). A dashboard. Ok, I will give you that.
  
  A storefront? Maybe, I guess..... what else? Tell me this: would you build an online employment application in Flex? How about a credit card application, or a patients' notes app for a physician or a part ordering system or a........THESE are the applications that are built in ColdFusion (at least in my experience, and I have been doing this for a fairly long time). Flex isn't ideal for ANY of them - you could force it I suppose (we DID, with the Flash Forms), but why force a square peg into a round hole WHEN YOU HAVE A ROUND PEG!!!!????
  
  I don't mean to rain on the Flex2 parade - rather, I am looking to be convined!

• Comment 26 written by Raymond Camden on 4 July 2006, at 7:22 AM

  

  There is a lot here, so I don't know if I could cover it all.
  
  Use of Flex: Ignore Flex for a minute and focus on RIA. If you need convincing that RIA's themselves make sense, I'm not sure what to say. Maybe I'm brainwashed but I thought it was obvious. Of course you wouldn't replace every web page with a RIA, but somethings really do make more sense as a RIA. Control panels, for example, make more sense as a RIA.
  
  I think we will definitely see folks misuse Flex, just as we saw folks make bad use of Flash, and CF, and .Net, etc. Any new tool will have sites that misuse the technology.
  
  As for speed in general, again, I know I've seen Flex2 apps load very quickly. They will never be as fast as plain jane HTML, but I think the trade offs are more than worthwhile, and save you time in the long run.

• Comment 27 written by Neil Bailey on 4 July 2006, at 11:44 AM

  

  Ray,
  
  Of COURSE I see the value in RIAs - the value is immeasurable in terms of web applications.
  
  My question is this: why not write RIA applications with a DHTML front end, a CFC handling the database (and whatever else needs handling) and an AJAX connector between the two?
  
  This will give you - in my mind, at least - almost the exact same capabilities (minus that slick Flash look of course), but with a load time that is about 40 seconds faster.
  
  My main question is not what you wouldn't use Flex for, but specifically what you WOULD use it for? I can think of a dozen RIAs off the top of my head without even really trying, but not a single one of them is a good fit for a Flex application - again, this is all my opinion. I am actually sincerely seeking to be convinced otherwise!

• Comment 28 written by Raymond Camden on 5 July 2006, at 8:34 AM

  

  Well bear in mind, we are only arguing about the view layer. Obviously Flex can talk to a CFC as well. I'd argue that, UI wise, Flex can do more than HTML can, or certainly can easier.

• Comment 29 written by Neil Bailey on 5 July 2006, at 9:52 AM

  

  But it also takes more than 10times as long to load.
  
  I still haven't been able to get a single real-world example - other than a dashboard - that is a perfect fit for Flex.

• Comment 30 written by Raymond Camden on 5 July 2006, at 10:01 AM

  

  As Simon said, you may have been looking at the wrong Flex2 apps. ;) I know most apps I've seen don't take long to load. Yes, they take more than HTML. A plain HTML page can load in less than one second. A Flex2 app may be 10 seconds, which makes your 10 times statement true. I don't think 10 seconds is a horrible wait time. Especially if thats the last big load.

• Comment 31 written by Neil Bailey on 5 July 2006, at 10:13 AM

  

  You are correct - I haven't seen a single Flex2 app written in the final release version of Flex2, nor a single Flex2 app run in the new FlashPlayer 9 (which, as you pointed out to me at CFUN, is supposed to have vastly improved performance).
  
  Unfortunately, my only frame of reference for real-world applications is Flash Forms. And Ray, they truly killed us - to the point that people almost lost their jobs@
  
  If real-world, functionality-heavy Flex2 apps are truly loading in 10 seconds, then I would agree that Flex2 is the RIA platform of TODAY, let alone tomorrow. I just haven't seen it.
  
  As for HTML load time: we have converted most (not all, yet) of our Flash Forms to HTML/AJAX, and the avg load time is about 5 seconds. If equivalent Flex apps were to load in...hell, 15 seconds, I would be happy (we're talking 6 grids, 5 tabs - each with..maybe 20 fields each; the grids need to be displayed dynamically, depending on the selected criteria, as do certain of the tabs).
  
  Also, I haven't YET heard of a single real-world application - again, I agree with the dashboard concept, regardless of the loadtime; so other than a dashbaord - that YOU feel Flex2 is IDEAL for.
  
  Thanks for listening to (reading??) my rambling.

• Comment 32 written by Kyle Hayes on 5 July 2006, at 1:32 PM

  

  Think of it as loading an actual desktop application.

• Comment 33 written by Neil Bailey on 5 July 2006, at 1:41 PM

  

  Yes, I understand the *concept*, its just that I don't know anyone writing desktop apps for the internet.... name 5 desktop apps that need to be delivered in a browser.... I know that I can't...
  
  Sure, I could write a Word Processor, but I have MS Office. Sure I could write a... hell, I dunno, anything, but the point is: WHY!
  
  My main point is this: I think flex2 will be a cool little toy. Again, it will be like the concept cars that the car companies put out: they generate a lot of discussion, and the whole world thinks that they're cool, but NOBODY DRIVES THEM TO WORK!!!
  
  I want my apps to look as slick and as cool as the next guy, but.... I, personally, just don't see much of a marketplace for this. After the initial "cool" factor dies down, I think this will be the next Spectra.
  
  And still, nobody has been able to tell me what they would use flex2 to build. Its like the emperor's new clothes - everyone says Flex2 is the future of the internet because everyone ELSE is saying that flex2 is the future of the internet.
  
  Or, maybe I am just missing the point...if so, tell me what you would build in flex2. Not a general category of applications like "desktop apps for the browser", but specifically, what? A dashboard. Ok. What else?

• Comment 34 written by tony weeg on 5 July 2006, at 5:10 PM

  

  and now its cool to make the link more NORMAL AND READABLE!!!!
  
  tony was a dumb ass for not seeing it... right :)
  
  ok, you can apologize at ANY time ray!
  
  later holmes.

• Comment 35 written by Gary on 14 July 2006, at 4:33 PM

  

  I took a few years off from CF and am now making a comeback. I'm getting the basic idea here, but I cant find an example of the actual CF code to use a query with SPRY. Can someone post an example? Thanks!

• Comment 36 written by Raymond Camden on 15 July 2006, at 4:21 PM

  

  I may not get you. You don't do anything different. You just make the CFC and use my ToXML to convert it to XML.

• Comment 37 written by Paul Baylis on 26 April 2008, at 7:43 AM

  

  Interested in toXML and watched your presos. Can't find demo.cfc anywhere in the download files. Where can I find that?

• Comment 38 written by Paul Baylis on 26 April 2008, at 7:45 AM

  

  sorry, "data.cfc" not "demo.cfc"

• Comment 39 written by Raymond Camden on 26 April 2008, at 9:48 AM

  

  I'm not sure what you mean by data.cfc. My CFC is toxml.cfc.

• Comment 40 written by Paul Baylis on 27 April 2008, at 3:16 AM

  

  In your Spry presentation to Auckland CFUG, you were working with data.cfc, invoking it with, e.g.
  
  <cfinvoke component="data" method="getData" returnVariable="data">
  
  and using it in Spry, e.g. as follows:
  
  <script type="text/javascript">
  var mydata = new Spry.Data.XMLDataSet("data.cfc?method=getdataXML","/people/person");
  mydata.setColumnType("age","numeric");
  </script>
  
  Just thought it might have been included with the download files. As a newby, I was just wanting to see how it all fits together.

• Comment 41 written by Raymond Camden on 27 April 2008, at 7:50 AM

  

  That CFC wasn't anything special - just a wrapper for demo data.

• Comment 42 written by Mamtha on 16 October 2008, at 12:48 PM

  

  I am working with a self referencing table that has id,name,parentid columns and am trying to generate hierarchical xml document so I can create a tree control in flex. how can I use toXml to achieve this?

• Comment 43 written by Raymond Camden on 16 October 2008, at 3:24 PM

  

  @Mamtha - toXML would not support that. It is mainly meant for Lists of data.

• Comment 44 written by Paul Klinkenberg on 25 February 2009, at 11:38 AM

  

  Hi Raymond and others, I used your original toXML component to create my own recursive toXML(data:any) function, which can take any data (except binary), and turn it into xml.
  
  You can read about it and download it here: http://www.leeftpaulnog.nl/2009/02/toxml-function-...
  
  Hope it's of use to someone; it helped me anywayz ;-)

• Comment 45 written by Roger on 20 July 2009, at 4:52 AM

  

  @Raymond: where can I find the "promised" rewritten code for the cfc's wich directly create xml for spry? not the toXML.cfc..

• Comment 46 written by Raymond Camden on 20 July 2009, at 5:27 AM

  

  XML for Spry? No idea what you mean. My toXML can be found at RIAForge.

[Add Comment] [Subscribe to Comments]