Submit Your Article
Lately, the committee has been looking at proposals to extend CFSCRIPT so that components can be written entirely in CFSCRIPT instead of requiring tags. Adobe has been the main driver for the proposals but other committee members have been providing their share of ideas and suggestions when we get stuck (or don’t like Adobe’s proposals).
Right now, we have a pretty solid definition of how CFSCRIPT should work so that you can write entire components. Mostly it follows what you may have seen Adobe show off at conferences but Adobe is still making changes in response to feedback from the committee (and its own banks of prerelease testers, I’m sure) and some of Adobe’s suggestions were considered vendor-specific by the committee.
But we’re stuck on a couple of tags that we’re really struggling to define in CFSCRIPT. We’d like you to help us make some decisions here!
First off, here’s a simple component written using core CFML2009:
import org.corfield.cfcs.*;
component extends=“BaseComponent” {
public any init( string fname, string lname, string addr ) {
variables.fname = fname;
variables.lname = lname;
try {
var country = getDefaultCountry();
variables.address = new gov.usps.cfcs.Address(addr,country);
} catch (any ex) {
writeLog(text=“Address failure”,log=“postal”);
throw(message=“Invalid Address”);
}
return this;
}
}
</cfscript>
Extended core CFML2009 would allow the <cfscript> tags to be omitted (with rules about what is allowable outside component). Extended core also adds a few other useful constructs that are optional for vendors (but if they implement them, they should follow the committee’s spec).
You’ll see import and new in here, as well as var appearing somewhere other than the top of the function. You’ll also see that we’ve voted to include throw in core CFML with a function-call style syntax that allows attributes to specified like named arguments. We’ve generally followed that pattern for tags-as-script, so you can say, for example:
// your code here }
But we’ve run into some problems trying to solve this for cfmail and cfquery. The problem is that the body of these tags is treated specially. It isn’t just code, it’s text with embedded code. You can see the problem clearly in this example:
I am text in the email!
but = i_am(“a”,functionCall());
}
In the tag-based version, it’s easy to identify code: it all begins with <cf or is wrapped in # but in CFSCRIPT, code looks like regular text.
Both cfmail and cfquery have nested tags and we can clearly put those in the tag-as-script body:
cfmailparam(…);
cfmailpart(…);
}
Since CFML allows multi-line strings, we’re considering adding a body attribute to cfmail and a sql attribute to cfquery so you could do this:
I am text in the email!”
;cfmail(body=myMail) {
// just code, including cfmailparam() etc }
We’ve reviewed a lot of syntax options and dismissed most as either unworkable for some technical reason or just downright ugly.
What would you like to see for mail and query in CFSCRIPT?
And, yes, we’re still discussing cfmail vs mail. For some tags, the name without the prefix is likely to clash with existing user variables and functions – and may not be as easy to read. For example, which of these two are more obvious and less likely to cause compatibility problems with your code:
httpparam(type=“cookie”,name=“uid”,value=“42″);
}
cfhttp(url=“http://foo.com/“,result=data) {
cfhttpparam(type=“cookie”,name=“uid”,value=“42″);
}
So, input please! On both the syntax for mail and query specifically but also tags-as-script in general.
Topics: ColdFusion, Programming
