CFM Templates And Remote CFCs - They're All Just ColdFusion Page Requests
I think a lot of ColdFusion developers never stop and realize that ColdFusion itself provides a pretty awesome framework. Hooks into this framework are provided by the Application.cfc event handlers. These event handlers provide all sorts of potential for scope initialization, plugin development, security hooks, and complete and total control over page flow. Sure, Application.cfc is nowhere near as beasty as something like ColdBox or Model-Glue which act more like full platforms; but, I don't think the ColdFusion framework should be glossed over in any way.
One reason to believe that a lot of developers don't actively think about the inherent ColdFusion framework is that they think about CFM and remote CFC method calls completely differently beasts. Granted, remote CFC method calls do some additional packaging as part of the ColdFusion framework, but when it comes down to it, both CFM and CFC calls are just ColdFusion page requests. When you think about them in this manner, you can finally think about them in the context of the natural ColdFusion framework control flow.
| |
|
|
|
|
| |
|
|||
| |
|
|
Now granted, hijacking a remote CFC method call doesn't add any value in this particular demonstration. The point here was not to say that this is how the ColdFusion framework aught be leveraged; the point here was only to demonstrate that ColdFusion does in fact provide and out-of-the-box framework that is quite powerful.
From what I saw at cf.Objective(), the custom frameworks that people have developed are quite amazing! Heck, ColdBox itself looks more robust than most full applications I build - I have every intention to look into them and see how they can be integrated into my future projects. But, I also want to stay grounded and realize that they are building on top of an existing, powerful framework that ColdFusion already provides.
Reader Comments
Maybe people are just impressed that CF8 lets you specify returnformat="plain" on remote method calls to let you get back a plain text response, since CFMX7 and before doesn't support returnformat and always wraps the response in a WDDX packet.
A few weeks ago I was working on a CFMX7 server and was disappointed when I realised I had to fall back to using a CFM page to wrap my CFC to get the response format I was after :P
I moved to ColdBox for my framework, and never looked back.
@Tim,
I saw Luis present at cf.Objective() on ColdBox and it looked really phenomenal.
When it comes to frameworks, however, I just want to make sure that things were not put in place due to any misunderstandings of how ColdFusion works. Not to say Luis would do that - he a freaking brilliant developer. I mean only to say that I want to make sure that things cannot be done more naturally in other ways.
I saw a bunch of things being auto-wired and auto-generated in all of the frameworks and I wanted to take some time and explore the idea that the inherent ColdFusion framework might make those things available in a more natural way.
I could be waaaay wrong :) But I figured it was worth exploring at some point.
@Ben,
Let me first say, I appreciate what you are doing. I really think it's great how you'd like to code "All natural". I'm a big fan of keeping as much control as possible, and letting the language do what it was designed to do. (Rather then pump everything through a framework.)
But yet, at the same time, two weeks after you found jQuery, did you say "Gee, this is handy, but can I do this more naturally"? (This is an extreme example I know, because if anything jQuery makes things almost more natural.)
So in the end, for me I think as long as I'm not sacrificing a cleaner more "natural" solution, what ever gets the job done most efficiently wins.
..Also, side-note, part of what I like about Coldbox is how natural it feels once you get into it. As well as the fact you aren't tied to it, you can have part of an application using it, and another part not using it, without doing gymnastics. (Plus I'm hoping you'll start using it, so I can get your fascinating insight on that along with CF and jQuery. :)
@Tim,
I 100% agree. I can write better programs with jQuery now than I ever could before! No questions asked. I suppose part of my hesitation is only that I don't know enough about the frameworks to see where the "pain" solution is.
In jQuery, for example, it's really easy for me to see what problems they are solving - easy DOM access / manipulation, unified event listening, etc.
When it comes to the CF frameworks, I guess I just need to dive in and try it out and see what problems they are solving. I think the problem is that my current application architectures are not big enough to have so much pain. But, if a framework can help me be MORE efficient, than I am all kinds of in favor of it :D
@Ben,
The "Pain" for me was MVC. ColdBox kinda forces me to code that way. That and layout management, coming from FuseBox my apps feel naked without layout wrappers like I'm used to.
@Tim,
Agreed - Layouts is something I would like to be forced to get better with too :D
Thanks u r information
I'm confused. This makes perfect sense, yet seems to completely contradict the well-known issue that OnRequest() interferes with remote accessed CFCs!
Indeed, when I implement OnRequest() my remote HTTP CFC calls fail. What am I missing?
I wish to implement one thing which OnRequest() seems ideal for: Authentication for all requests, which would then create certain variables within the VARIABLES scope.
When I place my authentication CFC into OnRequest() it works perfectly except then my remote access CFCs fail.
When I place it into OnRequestStart() I can't tell if it's working or not because the variables don't exist--I've read a little bit about placing/copying variables into the REQUEST scope, so maybe this is the problem, but I don't understand it very well yet.
[continued]
Thus,
(1) Why does OnRequest() work in your video, but not for my CFCs? See also:
http://corfield.org/entry/Applicationcfc__onRequest_and_CFCs
(2) Should I be using OnRequestStart() instead? What do I need to make the result variables available?
(3) I need my authentication to run for all HTTP requests: CFM and CFC. Seems I only get CFM's when using OnRequest().
Much thanks for all your posts. Very helpful. CF seems very arcane to me, but I'm learning!
I'm using CF8, by the way, so the new OnCFCRequest() isn't an option.
@Kevin,
The onRequest() event handler allows you to tell ColdFusion how *You* want to process the script request. If you leave that event handler out, ColdFusion will process the requests script for you by either:
1. Processing the requested CFM page and returning the output.
2. Invoking the requested CFC (component), packaging the response, and returning the packaged response.
If you want to do something differently or put some business logic around that request, you can use the onRequest() event handler to take control. However, as you are seeing, once you take control, there's a little more work to do.
It sounds like you don't want the extra work; as such, I would suggest moving your authentication logic to the onRequestStart() event handler.
When it comes to remote CFCs, as you are seeing, they have an entirely different Variables scope than that within the Application.cfc. You can store those values in the Request scope and those will be globally available, even within your requested CFCs.
Honestly, however, I am not a huge fan of using CFC's for API calls; I typically use CFM files for the request processing but use CFCs (components) for the business logic. It makes things - in my opinion - much easier.
If you want a really in-depth exploration of how the Application.cfc component works, take a look at my presentation:
www.bennadel.com/blog/1933-Mastering-The-ColdFusion-Application-Framework.htm
It doesn't cover the basics; but, it really digs deep and shows you how the incoming requests are processed.