NOTE: This is now obsolete. Use the method renderData() instead.

I really haven’t found a method I like that returns JSON via FW/1 until I saw a presentation by Steven Neiland the other day. Basically you have a few choices:

1. Call a service directly: This leaves you w/o any FW/1 features and the service is not initialized.
2. Create views that return JSON: This can become tedious and seems unnecessary, but FW/1 features are available
3. Have onMissingView handle it: Views do not need to be created and FW/1 features are available

My approach uses #3.

Example jQuery AJAX call:

$.ajax({
	url: 'index.cfm?action=products.attributesAJAX',
	type: 'GET',
	dataType: 'json',
	data: {parentPartNumber: $('#productForm').data( 'parentpartnumber' )}
});

You’ll notice it requests the section “products” and the action “attributesAJAX”. We will not create the view for the action, but we will create the controller method for it.

component {

	function init( FW ) {
		variables.FW = FW;
		return this;
	}

	// AJAX
	void function attributesAJAX( required struct RC ) {
		FW.service( 'productService.getProductAttributes', 'data', { parentPartNumber = RC.parentPartNumber } );
	}

}

To return JSON data w/o creating a view, we let the Application.cfc’s onMissingView method handle the return:

function onMissingView( required struct RC) {
	// if a data key exists, assume this is for AJAX and render as JSON
	if ( structKeyExists( RC, "data" ) ) {
		request.layout = false; // turn off default layout
		new services.utility().showDebugOutput( false );
		getPageContext().getResponse().getResponse().setContentType('application/json');
		return serializeJSON( RC.data ); // convert data to JSON
	} else {
		return view( 'main/pageNotFound' ); // set view to the missing page message
	}
}

You’ll notice that if the view’s missing it looks for the RC.data value. If it exists it assumes you want to return JSON back. Otherwise it will call the “pageNotFound” view (which you need to create). Note how the layout is turned off, it calls a method to turn off debugging (for development), and sets the content type to JSON.

This is the utility I created to turn off debugging:

<cfcomponent output="false">

	<cffunction name="showDebugOutput" output="false" returntype="void">
		<cfargument name="switch" default="false" type="boolean">
		<cfsetting showdebugoutput="#arguments.switch#">
	</cffunction>

</cfcomponent>

In FW/1 you have the variables.fw.service method to work with in your controllers. This method will run your service’s method and return the results to a key inside the RC scope. Keep in mind, however, these service calls are queued up and not run until the view is called. Why this is done I have no idea, but I’m sure there’s a reason.

Because they are queued, something like this would return a variable not defined error:

variables.fw.service ( 'users.get', 'userRecord' );
variables.fw.service ( 'geographic.getStatesByCountry', 'states', { userID = userRecord.getUserID() );

So after spending some time reading through threads on Google Groups, I determined the old fashioned way is the best way. However there’s a nice feature if you have a bean service defined such as ColdSpring. This feature implicitly sets a property named the same as a defined bean in your XML configuration. For example:

component accessors = true {
  property usersService;

  function init ( FW ) {
    variables.fw = arguments.fw;
    return this;
  }

  void function default ( RC ) {
    RC.performerRecord = getUsersService().get ( ID = 1 );
    variables.fw.service ( 'geographic.getStatesByCountry', 'states', { userID = userRecord.getUserID() );
  }
}

You don’t need use the fw.service on the last call, but I left it in there … just because.

What happens is FW/1 will look to see if each property defined matches a bean definition. If found it automatically sets the property to the bean. Otherwise you’d normally put something like this into your init:

setUsersService ( application.beanfactory.getBean ( "users" ) );

Here’s another “for later reference”…

Microsoft’s rules for .NET Framework 1.1 Abbreviations consist of:

• Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
• Do not use acronyms that are not generally accepted in the computing field.
• Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
• When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
• Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.

These appear to be good guidelines to follow for ColdFusion as well. I was going after casing for two letter acronyms in this case.

REF: http://msdn.microsoft.com/en-us/library/141e06ef(v=vs.71).aspx