I post a Lucee question on Stack Overflow

G'day:
Maybe you can help with this: "Associating child tag data with grandparent tag using CFC-based custom tags"?

CFML: That <cfexit> bug I thought I had spotted: solved

G'day:
Yesterday I asked for some help understanding a mismatch between some code and some docs: "Are the docs for <cfexit> wrong, or am I misunderstanding?".

I just looked at this some more, and discovered the docs are right, Railo is right, and <cfexit> is right. However there's still a bug in ColdFusion...

Here's a refined repro case:

<!--- testusingCfimport.cfm --->
<cfimport taglib="." prefix="t">
<t:basic>
    Text within tags<br>
</t:basic>
<hr>

<t:basic exitMethod="exittag">
    Text within tags<br>
</t:basic>
<hr>

<t:basic exitMethod="exittemplate">
    Text within tags<br>
</t:basic>
<hr>

<!--- basic.cfm --->
<cfparam name="attributes.exitMethod" default="">
executionMode: <cfoutput>#thisTag.executionMode#</cfoutput><br>
<cfif thisTag.executionMode EQ "start">
    <cfif len(attributes.exitMethod)>
        exitMethod: <cfoutput>#attributes.exitMethod#</cfoutput><br>
        <cfexit method="#attributes.exitMethod#">
    <cfelse>
        exitMethod: not specified<br>
        <cfexit>
    </cfif>
</cfif>

Railo: CFC-based custom tags

G'day:
As a baseline for some more research I am about to do, I wanted to get up to speed with how Railo implements CFC-based custom tags. I had read their blog articles about them:

• CFC-based Custom Tags by Example - Part 1
• CFC-based Custom Tags by Example - Part 2
• CFC-based Custom Tags by Example - Part 3

But it hadn't completely "sunk in" for me just by reading. I decided to work from top to bottom of the technology, demonstrating to myself all the various facets of custom tags and how they are implemented via a CFC. And here it all is...

Are the docs for <cfexit> wrong, or am I misunderstanding?

G'day:
Just before I update the ColdFusion docs and file a bug with Railo, can someone please santiy check this.

CFML: Follow-up on custom tag performance

G'day:
Yesterday I looked at memory leaks (or lack thereof) in custom tag usage: "Do CFML custom tags have an intrinsic memory leak issue?". There was no memory leakage, but what there was was pretty poor performance.

My suspicion was that it was down to there being a lot of string handling going on, as I had a custom tag around quite a lot of text, and text-handling is not a great performer.

Do CFML custom tags have an intrinsic memory leak issue?

G'day:
Betteridge's Law is very much in play with that headline. I guess that's a spoiler. But read on anyhow...

Situation

My previous article - I hope - out to bed the idea that there's a real-world performance consideration when it comes to using transient objects in CFML: "Hanging on to outdated knowledge: don't". This article will give the same treatment to the notion that CFML-based custom tags have an innate issue in that they cause memory leaks. TBH I have only ever heard this from one source, having researched thoroughly and polled the community could not turn up any corroborating evidence, and my own testing here will show: there doesn't seem to be a basis for it.


What I have heard is that back in the days of Spectra - which relies heavily on custom tags - people had performance and stability issues with Spectra-based sites. However as far as I can tell this had always been caused by one or more of the following sort of issues:

• sub-optimally-written code;
• trying too do too much with too little kit: under-provisioned hardware.

This sort of thing used to happen all the time with all sorts of CFML applications, and was not solely the domain of custom tag usage.

Another consideration is perhaps that this was back on old C++ -written versions of ColdFusion (pre 6.0), and those had intrinsic "idiosyncrasies" with memory handling.

So this is probably a case of throwing the baby out with the bath water.

CFML: Mostly pointless custom tag exercise

G'day:
Yesterday I wittered on about IRC, and how I landed there as part of an exercise to help Kyle with a code challenge he was having. Kyle wanted to know if it was possible to write a custom tag which emulated <cfmail> (easy), except including the fact one doesn't need to specify <cfoutput> tags in the body of a mail message with <cfmail>. That got me thinking.

First up, here's a <cfmail> example of what I'm talking about:

<cfset msg = "G'day world">
<cfmail to="dac.cfml@example.com" from="dac.cfml@example.com" subject="#msg#">
#msg#
</cfmail>

And this yields:

type:  text/plain; charset=UTF-8
server:  127.0.0.1:25
from:  dac.cfml@example.com
to:  dac.cfml@example.com
subject:  G'day world
X-Mailer:  ColdFusion 10 Application Server
body:   G'day world 

Note how #msg# was resolved in the body of the <cfmail> tag without there being any <cfoutput> tags around it.

If I was to knock out a quick mail.cfm custom tag and try that:

Custom tags: nesting

G'day:
I meant to write this one ages and ages ago, back when I did the previous article on looping with custom tags. As I said in that one, I think custom tags are a great concept, but have been a bit eclipsed by all the non-UI-centric things that have been added to ColdFusion in recent years, and they've fallen out of fashion a bit. I think they still have a place in CFML's arsenal, and do things in a way that is more elegant that other more recent alternatives, when used appropriately.

Custom Tags: Looping

G'day
Here's an unpopular / unloved topic: custom tags. I dunno if you're like me (poor you if you are ;-), but I spend most if my time these days writing the business logic parts of our app, and I certainly enjoy that part of my work more than the "presentation layer" stuff. I just find doing all the front-end stuff like the mark-up and styling it according to sometime else's idea of what looks good to be the tedious part of my work. I much prefer working on files that have a CFC file extension than CFM.

That said, one of the good things about ColdFusion is this whole mashing-up CFML and markup thing that ColdFusion makes so easy. However I think "ease of doing something" often leads to rubbish code: just because one can do something doesn't mean one should do it. Because it might not be a very good approach to things when one takes a broader view of things. To this end, I'm very keen on separating concerns into model, view and controller logic, whether it's done via a framework, or just a mindset and following some convention.