Thoughts on CFML tags, CFSCRIPT, Custom Tags and CFML2009
I've been following with some interest the work of the CFML Advisory Committee on the CFML2009 specification, particularly the proposed enhancements to CFSCRIPT. The question of being able to call Custom Tags from CFSCRIPT has helped crystalize thoughts I've been forming for some time regarding the relationship between CFML tags and CFSCRIPT, and how to write better CFML applications.
The thing that makes CFML great is its tag-based syntax when used to generate dynamic HTML content. CFML is simply unmatched by any other web application development language in this regard. In fact, you could argue that JSP tag libraries (including the JSP Standard Tag Library) and ASP.NET server controls are nothing more than attempts to mimic CFML tag-based syntax.
However, CFML tag-based syntax is awkward and verbose when writing lengthy computational or business logic that isn't generating HTML output. CFML suffers in comparison to other programming languages in this regard. But, this is where CFSCRIPT shines. It's unfortunate that many (most?) people only know about CFML's tag-based syntax and are completely unaware of CFSCRIPT; and, that CFSCRIPT has often been treated as secondary to the tag-based syntax by both CFML developers and CFML server vendors. Conversely, while CFSCRIPT is good for computational or business logic, you would not want to use CFSCRIPT and the writeOutput() function to generate large amounts of HTML content.
In summary:
CFML tags. Good (great!) for generating dynamic HTML content. Bad for writing computational or business logic.
CFSCRIPT. Good for writing computational or business logic. Bad for generating dynamic HTML content.If you accept this view, then the answer to the question of calling Custom Tags from CFSCRIPT is simple: don't do it. Custom Tags are an extension mechanism for CFML tag-based syntax. Custom Tags are intended to generate dynamic HTML content, not to contain computational or business logic. CFSCRIPT should be used for computational or business logic, not to generate HTML content. Calling Custom Tags from CFSCRIPT makes no sense.
Following on these thoughts, user-defined functions and components are extension mechanisms for adding computational or business logic to CFML, not for generating HTML content. In retrospect--and I'm not being critical here--the CFFUNCTION and CFCOMPONENT tags were probably a mistake. It might have been better for the CFML language and CFML developers if these features had originally been introduced and/or remained CFSCRIPT-only enhancements.
I welcome the proposed enhancements to CFSCRIPT, and have these suggestions for the CFML Advisory Committee and CFML developers:
- Don't add support for calling Custom Tags from CFSCRIPT to the CFML2009 specification. If it is added, CFML developers shouldn't use it.
- As soon as your favorite CFML server supports CFML2009 and the CFSCRIPT enhancements, ban the use of the CFFUNCTION and CFCOMPONENT tags. Require that user-defined functions and components be implemented using CFSCRIPT.
- Immediately ban the use of the writeOutput() function and require that all HTML content be generated using tag-base syntax.
Comments (2) |
2837 Views
bottom line, there are powerful features in things that folks sometimes want to "ban" - i say don't ban anything- programming, architecture and algorithms are as much art as they are science and everybody has their way of doing it - obviously there are "better" ways, but some elegant solutions can be hiding in features you havn't thought about - every problem domain warrants its own solution - so don't ban anything... in fact, i say bring on the <cfgoto> statement :-) (just kidding)
thanks for this post good reading and i mostly agree with your analysis - i just dont like to say "always" or "never" - ever
Suppose you have a component which has various functions that take input, process / format it and return HTML. Suppose some of this rendering functionality makes use of custom tags because some of the data is formatted in a complex, nested fashion. What you're proposing - not adding any kind of support for using (custom) tags to CFML2009's cfscript - limits the flexibility of cfscript to the point where this object *must* be written using cfcomponent / cffunction tags. Then consider a component that is initially written using script only, and at a later date needs to make use of an existing custom tag. You're then lumped with the task of rewriting the component to use cfcomponent / cffunction tags.
Why make script-only components inflexible in this regard? On Sean Corfield's blog there have already been 2 decent suggestions, an E4X-style syntax which definitely has potential, and a tag{} construct which is slightly more verbose but even more flexible.
Both suggestions solve (in addition to custom tags) the messy problem of cfquery and cfmail's tag body content and nested tags - simply keep using them as tags. We have to use them as tags right now, and what's so bad about it?
The E4X-style syntax could also give us the ability to create XML literals without having to write XML into a string or using cfsavecontent and then call ParseXML().
The tag{} construct is even more flexible as it would let you write blocks of CFML code, which could definitely aid in porting an application to a script-only style CFC.
Personally I would want to see both of these features in CFML2009.
And before anyone says it (yeah, trying to get most of my points out in one go here :)), I think any argument from potential "misuse" of the tag{} construct is a poor one, because it's not letting you write any "worse" code than you currently already write, it's just letting you use existing code. It is not a backwards step!
So in summary, you should be able to use script anywhere and you should be able to use tags anywhere. Limiting the language in either regard, as we have already learned with cfscript, is just silly.