DirectCFM: A ColdFusion Server-side Stack

[aconran]

Here is the first rendition of a simple server-side stack for the Ext.Direct protocol for ColdFusion 8. It requires the SerializeJSON function. If you are looking to use this with CFMX 6 or 7, you should look into integrating the CFJSON project.

It consists of 3 files:

1. Direct.cfc - Ext.Direct specific logic
2. Api.cfm - This is the file you will include via a script src tag to auto generate the API.
3. Router.cfm - This is the file which will route your request.

To use:
Create a folder in your CF project, for now i will call it "servicebus". Extract these 3 files into that folder.

After all of your standard page includes for javascript and CSS, link the Api.cfm page.

<script src="servicebus/Api.cfm"></script>

Configure where your router is located in Direct.cfc:

	<cfset variables.routerUrl = 'servicebus/Router.cfm' />

When your page now loads it will be creating an api descriptor in a javascript variable called Ext.ss.APIDesc.

You can configure this in the Api.cfm page:

<cfset args['ns'] = "Ext.ss" />
<cfset args['desc'] = "APIDesc" />

In order to start using Ext.Direct on the client side you will now have to add the API Descriptor as a provider within Ext.Direct.

var provider = Ext.Direct.addProvider(Ext.ss.APIDesc);

This is the generic setup, however we have not exposed any of our service CFCs yet. In order to expose a CFC, place it in the servicebus directory and add the ExtDirect meta attribute to the CFC and to each method you want to expose. For example:

<cfcomponent name="Echo" ExtDirect="true" >
	<cffunction name="send" ExtDirect="true">
		<cfargument name="data" required="true" />
		
		<cfreturn data />
	</cffunction>
</cfcomponent>

You will now be able to execute the Echo method after importing it (with addProvider).

Ext.ss.Echo.send('sample', function() {
    // callback here...
});

CFC methods can also be marked to be handled as a form post via an ExtFormHandler attribute. This is most commonly used for things like file uploads. For example:

<cfcomponent name="File" ExtDirect="true">
	<cffunction name="add" ExtDirect="true" ExtFormHandler="true">
		<cfargument name="formfield" required="true" />
		<cfset var file = '' />
		<cffile action="upload" filefield="#arguments.formfield#" result="file" destination="#expandPath('data/')#" nameConflict="MakeUnique"/>
		<cfreturn file />
	</cffunction>
</cfcomponent>

Note here that we needed to specify what the name of the formfield is when we upload. This is a CF specific issue which was detailed a ways back by Ben Nadel I think... I'll try to find the blog entry.

[aconran]

The blog entry which I referenced above was actually an entry by Sean Corfield that can be found here: http://corfield.org/blog/index.cfm/d...pload_and_CFCs

[brookd]

I am using AJAXCFC to be able to call CFC's directly from within EXT. The syntax is more verbose, are there any other major differences that you know of?

A simple AjaxCFC call looks like something like this:

	    jQuery.AjaxCFC({
		  url: "/adapter/coreAdapter.cfc",
		  method: "keepAlive",
		  data: {loadClientData:true},
		  serialization: "json",
		  debug:false,
		  useDefaultErrorHandler: false,
		  success: function(result){
	
		  }
		});

[kanntronics]

I think DirectCFM is purposely for Ext.Direct stuff..

To make a simple ajax request to cfc, you can do like this:

Ext.Ajax.request({
  url: 'data.cfc',
  method: 'post',
  params: {
       method: 'cfcFunc',
       param1: 'val1'
  },
  success: function(r){

  },
  failure: function(r){

  }
});

[aconran]

I am using AJAXCFC to be able to call CFC's directly from within EXT. The syntax is more verbose, are there any other major differences that you know of?

brookd -

DirectCFM was created to integrate with Ext.Direct and therefore works very well with all of the Ext components and the Ext.data package. Check out the Ext.Direct blog entry which we posted this morning which may explain more about direct.

I'm not that familiar with AjaxCFC, but had used cfajax several years ago which was Rob Gonda's original project circa 2005. A few added benefits of DirectCFM:

• Ability to execute methods like 'normal' Users.getUsersByGroupId(462)
• Intrinsic Batching, calls will be batched together in a single request
• Support for file uploading - does ajaxCFC support this?
• Integration with Ext

[dawesi]

I have two questions regarding this:

1) In ColdFusion terms, why wouldn't you use an ajaxProxy (I use a homegrown version) instead of your router?

2) Secondly, if you have an intranet app, you may have hundreds of exposed methods for a business object. Does this mean all of them are written to the javascript file?

[dawesi]

3) Why wouldn't you just wrap the whole lot into extdirect.cfc?

4) At what level would you apply your security context, as some people may not have permission to various pages, so you would have to then remove objects referencing items you don't want people to see. Also sometimes you don't want people to know every method that is available, you then need to create a security proxy for the server-side code? How would you suggest going about this.

[kanntronics]

4) At what level would you apply your security context, as some people may not have permission to various pages, so you would have to then remove objects referencing items you don't want people to see. Also sometimes you don't want people to know every method that is available, you then need to create a security proxy for the server-side code? How would you suggest going about this.

Just share some thought..

security context should be managed at server side code.. in my application, I manage the security in Application.cfm; any access to cfm or cfc must passed the Application.cfm authentication via <cflogin>.

in my case, i don't care if all my method exposed @ client side as long they cannot access it. By looking @ DirectCFM code, only component / function with 'ExtDirect' attribute will be exposed to the client

Cheers..

[dawesi]

@kanntronics... you should care... exposed methods are an attack surface.

ah... ExDirect attribute... if only I used tags instead of script...bummer... unusual way to generate code reading the file structure tho.. would be fairly slow, but I guess it is cached by the browser

[aconran]

3) Why wouldn't you just wrap the whole lot into extdirect.cfc?

Most of the functionality is wrapped inside of Direct.cfm. Initially i had this implemented as a single Application.cfc file which you could drop inside a "service" directory and then it handled all sorts of things such as security etc. However, I thought that this would be too limiting to many users and refactored it into the 3 file structure it is now.

4) At what level would you apply your security context, as some people may not have permission to various pages, so you would have to then remove objects referencing items you don't want people to see. Also sometimes you don't want people to know every method that is available, you then need to create a security proxy for the server-side code? How would you suggest going about this.

You can customize what is sent down to the client via any application specific logic that you want. This could be a new custom attribute such as a Role like "Administrator", "Moderator", "User" or it could be something more fine grained such as the users userId and a complex set of permissions that are stored in a db/file system/web service call somewhere.

Perhaps this would be best done by allowing users to provide a filter in Direct.cfc getAPIScript immediately before outputting the API spec. What do you think?

EDIT: As I posted above the invokeCall method in the CFC should be checking to make sure that ExtDirect attribute is set on both the CFC and Method.

As another poster mentioned all of your other security constraints should be handled at the server-side just like we've done in the past in a typical Ajax app.