> No it's not, in and of itself. > However, thanks to CFMX, you can now build CFML-style UDFs, and thus > swap out a CFML call with a CFSCRIPT-like UDF call.
> Check out http://www.cflib.org/, if you haven't in the past. The > libraries are full of these. > Robert Everland wrote: >>I use it as much as I can also, but it is by no means a replacement for >>many >>of the cf tags. >> >>Robert Everland III >>Web Developer Extraordinaire >>Dixon Ticonderoga Company >>http://www.dixonusa.com >> >>-----Original Message----- >>From: Kreig Zimmerman [mailto:kkz@;foureyes.com] >>Sent: Wednesday, October 30, 2002 12:34 PM >>To: CF-Talk >>Subject: Re: OT:Yahoo moving to PHP >> >> >>That's pretty much what I've done at my company as well. >> >>CFSCRIPT is just so much cleaner, and easier to read. >> >>CFML tends to be only used when we are annotating HTML. In which case cf-tags are then much cleaner and easier to read than equivalent cfscript, i.e. <cfquery> ... </cfquery> <cfscript> // create a table writeoutput('<table class="mytable" cellspacing="0">'); // create a header row writeoutput('<thead class="mythead"><tr><th>Hello</th><th>World</th></tr>'); // output the body of the table writeoutput('<tbody class="mytbody"><tr>'); for ( x=1; x lte myquery.recordcount; x = x+1 ) { writeoutput('<tr>'); writeoutput('<td>#myquery.mycolumn[x]#</td>'); writeoutput('<td>#myquery.mycolumn2[x]#</td>'); writeoutput('</tr>'); } writeoutput('</table>'); etc... vs. <cfquery> .... </cfquery> <!--- create a table ---> <table class="mytable" cellspacing="0"> <!--- create a header row ---> <thead class="mythead"><tr><th>Hello</th><th>World</th></tr></thead> <!--- output the table body ---> <tbody class="mytbody"> <cfoutput query="myquery"> <tr><td>#myquery.mycolumn#</td><td>#myquery.mycolumn2#</td></tr> </cfoutput> The trick, if you can accomplish it, ( and it's much easier with MX ) is to encapsulate enough of your processes and business logic into functions and cfc's that your display elements never have to include cf tags, and if you really get deeply into it, they may never need to really include much html... i.e. if you had cfc's and cf functions to handle your entire display layer, the above 2 codeblocks could become something like: <cfoutput> #request.udf.tableOpen("mytable",0)# #request.udf.tableHeader("mythead",ListToArray("Hello,World",","))# #request.udf.tableDataOut("mytbody",myquery,mycolumnlist)# #request.udf.tableClose()# </cfoutput> or further still encapsulate this into another udf: function tableOut(tableclass,cellspacing,headerclass,headerarray,bodyclass,d ataquery,columnlist) { return htmltable = request.udf.tableOpen(tableclass,cellspacing) & request.udf.tableHeader(headerclass,headerarray) & request.udf.tableDataOut(bodyclass,dataquery,columnlist) & "</table>"; } request.udf.tableOut = evaluate("tableOut"); Then the previous cfoutput becomes something like this: <cfscript> mycfc.getSomeData("myquery"); aHead = ListToArray("Hello,World",","); mycolumnlist = "foo,bar"; writeoutput(request.udf.tableOut("mytable",0,"mythead",aHead,"mytbody",myqu ery,mycolumnlist)); </cfscript> Or further still <cfscript> mycfc.displaySomeData("mytable",0,"mythead","mytbody","Hello,World","foo,ba r",","); </cfscript> In this case where the mycfc.displaySomeData() function utilizes the afforementioned generic display functions to output data it knows how to fetch internally, and you just provide it with style and column information for the purpose of the display. Some people might say this is bad form, since it encapsulates display in the CFC which should be "reserved for business logic" but the display isn't actually being output from the cfc, it's being output from generic display UDF's -- or from another UDF designed to handle the display layer of your appplication. Given my druthers, I think I'd opt to use something like this last one, since it represents a maximum amount of code-reusability and a minimum number of keystrokes both in initial development and in later revisions. In just this example alone, I condensed 20 lines of combined cf tags and cfscript to 1-3 lines of code, and I'm all for anything that gives me a 20:1 compression in development time. Without MX it's not really practical tho, so I'd opt largely for something like the 2nd example in CF 5 and prior. Mostly because I can't easily abstract calls to the database into UDF's in CF 5. But in MX, once you've done the leg-work of abstracting the display layer of your application or site either as a CFC or a collection of UDF's, then doing everything in <cfscript> becomes a natural alternative. And I don't even use MX yet. :P S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
