Which is better: having your methods inline in a CFC, or included from a separate file? (cont'ed)

This is just a reply to Henry, Shawn and Dave regarding my earlier posting on this topic, but as it's longer than 4kB, I cannot post it as a comment to the original post, so I'm creating a new one.

Hi guys. I didn't reply to the bulk of this last night cos I was watching a movie(*) and could multi-task enough to keep an eye on the #ColdFusion channel on Twitter, but not enough to give my reply to you the attention it warrants.

@Henry. Yeah, I too am let down by the lack of static methods in ColdFusion, and for the same reason. I have hit Adobe up about this a coupla times (for CF9 and for CF10), but I'm always swamped by colleagues saying it's to complicated to implement (this was not from Adobe, but a CF community member, so dunno if that has merit); most CF developers are too "junior" to understand what they are so it'd be wasted on them; you can work around it easy enough; ColdFusion is all about simplicity, and this concept is to complicated; and that old specious chestnut "if you want to use Java, use Java". Which is all a mix of faulty logic or is just plain facile. Still: the idea always garners this negative criticism, so I guess it didn't seem compelling to Adobe. Anyway: we are where we are... no static methods.

Which is better: having your methods inline in a CFC, or included from a separate file?

A question came up on StackOverflow about whether it's "better" to compose a CFC vis a single CFC file, out to include the methods via <cfinclude>. Thus is an interesting topic (after a fashion), so I decided to look into it some more, beyond the answer to the specific question on StackOverflow.

Just to set a baseline, what Henry was asking is whether there are performance considerations when contrasting these two approaches to composing a component:

<!--- MethodsInline.cfc --->
<cfcomponent>
    
    <cffunction name="publicMethod" access="public" returntype="struct" hint="This is my public method">
        <cfreturn arguments>
    </cffunction>
    
    <cffunction name="privateMethod" access="private" returntype="struct" hint="This is my private method">
        <cfreturn arguments>
    </cffunction>
    
    <cffunction name="packageMethod" access="package" returntype="struct" hint="This is my package method">
        <cfreturn arguments>
    </cffunction>
    
    <cffunction name="remoteMethod" access="remote" returntype="string" hint="This is my remote method">
        <cfargument name="who" type="string" required="true">
        <cfreturn "hello, #arguments.who#">
    </cffunction>
    
</cfcomponent>

CFML: The difference between events and event handlers

G'day:
Here's another quick about Application.cfc.

In a conversation a few weeks back I was talking with a colleague about the applicationStop() function that was added to ColdFusion in CF9. Docs here.

I can't recall the exact gist of the conversation, but we got to the point where my colleague suggested that rather than stopping the application, it could simply be restarted by calling onApplicationStart() (or a combination of onApplicationEnd() and onApplicationStart() or something). This is the same conversation that resulted in my earlier post about the single-threadedness of onApplicationStart().

One thing to bear in mind here is that calling onApplicationStart() does not start your application. It's just something that gets called when ColdFusion starts the application. Obviously a lot of what constitutes your application being in a "started" state is the code that gets executed when onApplicationStart() runs, but onApplicationStart() is not in and of itself what causes an application to start.


Similarly, onApplicationEnd() doesn't end your application. ColdFusion handles the application ending... it just has the courtesy of allowing use to specify some of our own code that runs when it takes the application down. Same with sessions: running onSessionStart() doesn't start a session, and running onSessionEnd() doesn't stop the session. And, yeah, samesame with onRequestStart() and onRequestEnd(): they don't start and stop a request (those two are a bit more obvious).

This might seem obvious to people, but it does trip a lot of people up, and I include myself in that group until I sat back and reflected one day.

The thing is that there's two different notions here; an event, and an event handler. In the process of going about its business, ColdFusion will cause events to happen, such as starting an application, session or request, and at some later point in time it ends them too. But those are the events, and it's ColdFusion that performs them. What Application.cfc gives us is the ability to specify event handlers which ColdFusion calls as part of it performing the actual event. So ColdFusion performs/executes/whatever-you-want-to-call-it an event (I dunno what the best technical term is? Anyone?), and then it calls our event handler from Application.cfc. What this doesn't mean is that the opposite is true: running the event handler doesn't cause the event to occur.

A way to easily see the distinction here is to forget about ColdFusion and think about JavaScript for a moment. If one clicks a mouse button, a click event occurs, and in turn an onClick event handler could run. However the reverse is obviously not true: running the onClick handler obviously doesn't cause the mouse button to depress. That's probably a good way of thinking about it. It's certainly helped me keep it straight in my head.

And now it's time for the pub.

--
Adam

What one can and cannot do with <cfqueryparam>

G'day:
Looking at how other languages handle DB interaction, <cfquery> is one of the best things about CFML.  It's just so easy.  We all know how it works, but here's a pointless reminder of what you already know:

<cfquery name="q" datasource="dsn" result="stResult">
    any old string you like
</cfquery>

In its most basic usage, ColdFusion takes the string and sends it to the DB driver.  The DB driver passes this to the DB, the DB does something with it and sends back a response to the DB driver and then to ColdFusion, and ColdFusion exposes via the variable named in the NAME and/or RESULT attributes (I'm not going to repeat the docs, which are here: go read 'em).

Another thing that ColdFusion does really nicely is play with strings, inline in the body of your CFM file.  We might have this SQL to pass to the DB:

CFML: onApplicationStart is not intrinsically single-threaded

G'day:
I read somewhere today someone say onApplicationStart is single-threaded, as a justification for removing a <cflock> from some code that was causing another person some problems.

In the explicit context under discussion the person was offering good advice, but the blanket statement that onApplicationStart is single-threaded is not entirely accurate.

In ColdFusion, application-start-up is single-threaded. And during application start-up onApplicationStart is called. So that call to onApplicationStart is also single-threaded.

However the single-threadedness here is not intrinsically related to onApplicationStart.