Fusioncube » coldspring

New AjaxCFCProxy class for Sencha ExtJS

Steve Brownlee — Fri, 15 Apr 2011 15:47:56 +0000

Related Article(s): AjaxCFC ported to ExtJS

My integration of ExtJS, ajaxCFC and ColdFusion continues.

Note: This is for version 3.3.1. I’ve also been happily playing around with version 4, but until it’s officially released, I must continue building with 3.3.1.

Anyway, here’s what I was trying to solve. When I want to allow users to serach for items from a ComboBox, I configure a store, and inside the store, I configure an Ext.data.HttpProxy to hit a separate ColdFusion page that performs a query and returns the results.

Standard HttpProxy Method

var WidgetStore = new Ext.data.Store({
    proxy: new Ext.data.HttpProxy({
        url: 'liveQueries/widgets.cfm'
    }),
    reader: new Ext.data.JsonReader({
        root: 'data',
        totalProperty:'totalRecords'
    }, Widget)
});

ColdFusion ‘Live’ Query






SELECT UNIQUE widget_seq_no, identifier, descr
FROM 	widgets
WHERE 	(REGEXP_LIKE(identifier,,'i')
   OR REGEXP_LIKE(descr,,'i'))
   AND widget_type_cd='SNAPPYDS'
ORDER BY identifier asc



jsonBean = createobject("component","ajaxCFC.JSON");
jsonEncodedCriteria = jsonBean.encode(data=chargeCodes, queryFormat="array");
writeOutput(jsonEncodedCriteria);

I hate this, because I already am using my Ext.AjaxCFC class to query my ColdSpring beans asynchronously, so why do I have to set up these standalone ColdFusion pages to performs queries that should be executed in the component?

I decided to take matters into my own hands, and I have to give the ExtJS team props again, because it was easy to accomplish by extending the Ext.data.MemoryProxy class. As you can see, all I need to do is override the doRequest() method to execute Ext.AjaxCFC.request() with the data passed in during initialization.

Ext.ux.data.AjaxCFCProxy.js

Ext.ns('Ext.ux.data');

Ext.ux.data.AjaxCFCProxy = Ext.extend(Ext.data.MemoryProxy, {
   constructor : function(data){
      Ext.ux.data.AjaxCFCProxy.superclass.constructor.call(this);
      this.data = data;
   },
   doRequest : function(action, rs, params, reader, callback, scope, arg){
      this.data.data.query = params.query;
      Ext.AjaxCFC.request({
         bean : this.data.bean,
         method : this.data.method,
         data : this.data.data,
         success: function(rs) {
            var result = reader.readRecords(rs);
            callback.call(scope, result, arg, true);
         },
         error: function(results) {
            Ext.MessageBox.alert('Load Failed', 'Unable to load requested data');
         }
      });
   }
});

New and Improved Combobox for Searching

WidgetSearch = new Ext.form.ComboBox({
    minChars:           2,
    loadingText:        '',
    itemSelector:       'div.search-item',
    triggerClass:       'x-form-search-trigger',
    emptyText:          '',
    width:              300,
    listWidth:          0,
    store: new Ext.data.Store({
        // I've extended the base Ext.data.MemoryProxy()
        // class to use the AjaxCFC object for searching
        // instead of having to use a liveQuery. Much cleaner.
        proxy: new Ext.ux.data.AjaxCFCProxy({
            bean    : 'Widget',
            method  : 'search',
            data    : { source_table : 'WIDGET' }
        }),

Porting my ColdSpring-enabled AjaxCFC code to ExtJS

Steve Brownlee — Tue, 07 Dec 2010 17:28:33 +0000

I’ve been using the AjaxCFC library for years. It’s my preferred way of integrating Javascript and ColdFusion via AJAX. I’ve even modified it from its original form so that my implementation was strictly for integration with jQuery, only returns JSON strings (ignoring WDDX and simple string), and can work with ColdSpring.

Now that I’m a heavy user of the Sencha ExtJS framework, I thought it would be useful to port the jQuery.ajaxCFC.js file over to an Ext.AjaxCFC.js file that extended the native Ext.data.Connection class and utilized the Ext.Ajax object.

Took me about half the day, but I finally got a working Ext.AjaxCFC.request() method that uses the same syntax as the $.AjaxCFC() method. For those familiar with the inner workings and code of the jQuery AjaxCFC class, this will look very familiar.

So now I can make AJAX calls using native ExtJS classes, access ColdSpring beans in my application’s bean factory, or connect directly to any CFC

Ext.AjaxCFC.js

Ext.AjaxCFCConnection = Ext.extend(Ext.data.Connection, {
   data        : null,
   queryFormat : 'array',
   factory     : (typeof(__ajaxConfig) == 'undefined') ? null : __ajaxConfig.beanFactory,
   timeout     : (typeof(__ajaxConfig) == 'undefined') ? 30000 : __ajaxConfig.defaultTimeout,
   url         : __ajaxConfig.url,
   bean        : null,

   request : function(arguments) {
      var params = (typeof(arguments.data) == 'undefined') ? {} : arguments.data;
      arguments.params = {};
      arguments.params['C0-ID']         = (Math.floor(Math.random() * 10001) + "_" + new Date().getTime()).toString(),
      arguments.params['method']        = 'init';
      arguments.params['component']     = arguments.component;
      arguments.params['bean']          = (typeof(arguments.bean) == 'undefined') ? this.bean : arguments.bean;
      arguments.params['factory']       = this.factory;
      arguments.params['C0-METHODNAME'] = arguments.method;
      arguments.params['queryFormat']   = (typeof(arguments.queryFormat) == 'undefined') ? this.queryFormat : arguments.queryFormat;
      arguments.params['C0-PARAM0']     = params;

      arguments.url = this.url + '?method=' + arguments.params['method'];
      arguments.method = 'POST';
      arguments.failure = arguments.error;
      arguments.timeout = this.timeout;

      var ____success = arguments.success;

      arguments.success = function(data) {
         data = data.responseText.replace(/^\s*|\s*$/g, '');

         if (data.substring(0,9) == '__json__:') {
            data = Ext.util.JSON.decode(data.slice(9));
         }
         ____success(data, this);
      };

      if ( params ) {
         if (typeof params != 'string') {
            arguments.params['C0-PARAM0'] = Ext.util.JSON.encode(params);
         }
      }

      Ext.Ajax.request(arguments);
   }
});

Ext.AjaxCFC = new Ext.AjaxCFCConnection();

Usage

// Include Ext.AjaxCFC code


// Default configuration properties for the ajaxCFC library
__ajaxConfig = {
   'url':'/myApp/ajaxCFC/ajax.cfc',
   'defaultTimeout':30000,
   'beanFactory':'application.beanFactory'
};

// AjaxCFC call using Ext.data.Connection class
Ext.AjaxCFC.request({
   bean: 'AColdSpringBean',
   method: 'aMethod',
   data: {
      'id': 416198,
      'first_name': 'Steve',
      'last_name': 'Brownlee'
   },
   success: function(details, s){
      DataStore.loadData(details);
   },
   error: function(results){
      Ext.MessageBox.alert('Search Failed', 'An unexpected error occurred. Please try again.');
   }
});

ColdFusion Object Creation – More

Steve Brownlee — Fri, 13 Feb 2009 04:51:52 +0000

Following up on my original post about ColdFusion performance hits on creating objects – it was suggested that I return an array of typed structures instead of an array of components.

I already had a nice AOP class for each of these scenarios, so all I had to do was add the __type__ column to the array of structures, and I was good. The test results below seem logical… except for the first set of testing 50 rows. Converting the query results into an array of structs using a simple function call to another component was actually SLOWER than using AOP or converting to DTOs.

Besides that anomaly, the performance hit for using ColdSpring AOP proxies and using DTOs is clearly visible as you add more data.

ColdFusion to Flex Object Type Conversion via ColdSpring

Steve Brownlee — Thu, 02 Oct 2008 19:26:04 +0000

The Value Objects

Otherwise known as a transfer object is simply a design pattern for exchanging data between disparate systems. I’m working on a application with a Flex UI and a ColdFusion backend, and I initially discovered that if I return a query directly to Flex, it is converted into an ArrayCollection populated with simple Objects.

What I wanted was an array of specifically typed objects that I could cast as value objects in Flex. Here’s a very simplistic example of an Employee value object in Flex. It has two properties:

Employee ID
Employee Name

Flex Employee Value Object

package net.fusioncube.transferObjects
{
   [RemoteClass(alias="net.fusioncube.model.employee.Employee")]
   [Bindable]
   public class Employee
   {
      private var _employeeID:uint;
      private var _employeeName:String;

      /* constructor */
      public function Effort(employee_id:uint = 0,
                  employee_name:String = "")
      {
         this._employeeID= employee_id;
         this._employeeName= employee_name;
      }

        public function get employee_id():uint
        {
        	return _employeeID;
        }

        public function set employee_id(value:uint):void
        {
        	if(value != 0) _employeeID= value;
        }

        public function get employee_name():String
        {
        	return _employeeName;
        }

        public function set employee_name(value:String):void
        {
        	if(value != "") _employeeName= value;
        }
   }
}

You may have noticed the RemoteClass metadata applied to the Actionscript class. What this does is ensure that this Flex class maps directly to a ColdFusion component value object. To make a ColdFusion component value object is simple: you use the tag for each property and specify each one’s type.

In this example, I’ve also added an init() method, whose use we’ll discover later.

ColdFusion Employee Value Object

Converting a Query to an Employee Array

Again, as a very simple example, let’s say I have an EmployeeService component in my service layer and have a method listEmployees() that simply queries the employees table and returns all rows.


   

   
   select e.* from employees e

Since I don’t want to return a query, and I certainly don’t want to have two methods in every single component – one that returns a query and one that returns an array of objects – I use the handy, dandy AOP feature in ColdSpring to apply an advice that does it at runtime.

QueryToVOAdvice Advice

In this advice, I simply loop over the query’s rows and columns to create a simple structure containing the key/value pairs for each row. It then creates a new component for each query row by passing that structure to the init() function – which you saw above – and adds it to an array.

The result is an array of Employee-typed objects.



   
      
   

   
      

      
      var local = structNew();
      local.queryRow = 1;

      // Create an array to hold the value objects
      local.valueObjectArray = ArrayNew(1);

      // Store the resulting query object from the method execution
      local.queryObject = arguments.methodInvocation.proceed();

      // Loop over the query rows
      for(local.queryRow=1; local.queryRow lte local.queryObject.recordCount; local.queryRow = local.queryRow+1)
      {
         local.voStruct = structNew();

         // Loop over the query columns and create a key/value pair for each value
         // in this row of the query
         for(local.columnNum=1; local.columnNum lte listLen(local.queryObject.columnList); local.columnNum = local.columnNum+1)
         {
            local.columnName = listGetAt(local.queryObject.columnList, local.columnNum);
            local.voStruct[local.columnName] = local.queryObject[local.columnName][local.queryRow];
         }

         // Create an instance of the value object (obtained from the getValueObject method)
         // initializing it with the structure we created.  Add the value object to the array.
         arrayAppend(local.valueObjectArray, createObject('component', arguments.methodInvocation.getTarget().getValueObject()).init(argumentCollection=local.voStruct));
      }

      return local.valueObjectArray;

ValueObject Property

For each of my beans, in this case the Employee bean, I can simply apply an advice in the definition. For this to work, I create a valueObject property in each component.

Employee Bean Definition

Now when I define my Employee bean, I specify the type of the value object (the type that gets returned from the init() function), and then apply the advisor (shown below).


   
      
         
            net.fusioncube.model.employee.Employee
         
      
   
   
      
         queryToValueObjectAdvisor

QueryToValueObjectAdvisor Definition


   
      
   
   
      ^list.*$

The Flex Array of Typed Objects

Here’s an image of an example array I get back from ColdFusion in one of my current apps. You can see that each object was automatically converted into a Teammate (equivalent of an Employee) rather than a simple Object.

Caveat: If you’re passing back queries with a thousand or more rows, and are running CFMX 7 or older, then this solution may cause serious performance problems as object creation is notoriously “slow” in those versions of ColdFusion.

When to use autowiring in ColdSpring

Steve Brownlee — Mon, 15 Sep 2008 19:38:23 +0000

Autowiring in ColdFusion

Most of you may have heard of autowiring, and many of you may have implemented it in an application by now (most likely with Spring, ColdSpring, or Google Guice).

If you don’t know what autowiring is, or are curious about how to do it, I’ll simply direct you to other people who have adequately explained it (see reference links at bottom of article) rather than doing it myself. This article is about when to use it, not how to use it.

Most people I talk to, or have read articles by, promote autowiring as a positive thing. It offers an effective way to automatically inject instantiated components into other components that require their methods. Who wouldn’t be a fan of that??

Nevertheless, there are gadflies who point out that the overuse of autowiring defeats one of the benefits of your bean definition file: a documentation tool. It is the one place in your application that clearly shows how services depends on each other. I believe this is a valid point, as I often use my definition file as a quick reference to my application’s dependencies.

Autowiring Incidental Dependencies

I prefer to use the autowiring feature for beans that are not business logic:

Datasources
Configuration settings
Resource libraries (e.g. Transfer ORM)
Transfer/Value objects

For example, several of my apps are written using Model-Glue, and I define beans to pass the application’s datasource, and transfer service:

Most of my beans require one, or both, of these services, and I’m reluctant to pass them in as constructor arguments since I consider them incidental dependencies, rather than logical dependencies. I see no benefit in having these clutter up my definition file since they offer no help to me, or anyone else, when determining if the Facility component requires the use of the Organization_Demographics component or not.

Instead of having dozens of these definitions filling up my definition file:


   
      
         
            
         
         
            
         
         
            
         
         
            
               
                  
               
               
                  
               
            
         
         
            
         
      
   
   
      
         exceptionLoggingAdvisor

Instead I enjoy looking at a definition file that shows me how I’m wiring my application together.


   
      
         
            
         
         
            
         
         
            
          
      
   
   
      
         exceptionLoggingAdvisor

Reference Links

Joe Rinehart on autowiring
Nando demystifies autowiring
Download a small, sample app that provides autowiring code

The ColdFusion ServiceRunner – Part I

Steve Brownlee — Wed, 27 Aug 2008 22:54:19 +0000

I’ve been meaning to share this for many reasons, but I’ve been bogged down with projects lately. However, it has allowed the code to mature and get streamlined a bit, so it’s good that some time has passed.

This is a pattern that we’ve come up with at work to handle remote calls to ColdFusion. It is one part of our SOA initiative that allows ColdFusion and Flex developers to make service calls to our core business components using a common approach.

I’ll start at the high level and work my way down. The reason I started this project is because early on I started to notice that there were many common entities used throughout the gamut of application used by my business unit – Facilities, Teammates, Drugs, Treatments, Patients, Doctors, etc…

Each application developer had written their own code to handle retrieving information on each of these entities. I’m sure you can see where the problem is in that, so I won’t belabor the point. To stop the fragmentation, I began diagramming how to create a common service application that could be accessed by any client in the company using a simple interface.

The Remote Call Service – RemotingService.cfc

Let’s start off with the first part of the puzzle: the simple interface for calling ColdFusion Component methods in our service application.

Can’t get more simple than this. Using any remoting technology supporting SOAP, any client can invoke this component’s invokeService() method. This is the one entry point into our service application. As I’m sure you noticed by the application.beanFactory code, we’re using ColdSpring to manage all of our dependencies, AOP features, and event maps (more on this later).

The Service Response Value Object – ResponseVO.cfc

The next concept we tackled was not returning complex objects; we wanted a simple and logical structure to what gets returned to the client. Also we didn’t want the response object sitting around in memory sucking up RAM on the machine. We wanted this object to be created and destroyed on each remote request (shows below in the ServiceRunner code).

What got created was a simple Value Object that defines the keys of the response: name of the event, a success boolean, the data object, and an error structure (which is only populated if an error occurs).

The Service Runner – ServiceRunner.cfc

Once we’d defined how services would be called and what the response would be, we then had to write the mechanism to actually execute the method and populate the response VO. The service runner is defined as a bean via ColdSpring (shown below) and is instantiated from the RemotingService component (shown above).

The RemotingService then calls the public run() method which creates a VO, executes the requested event using the private runEvent() method, and then returns the populated VO.

Defining Events as Beans – EventMaps.xml

To define our events, we create a bean for each one using the RemoteEventMap.cfc as the template for each one. The RemoteEventMap (code shown below) has two properties: beanName and methodName. These are used in the runEvent() method of the ServiceRunner (shown above) to obtain the properties needed for the CFINVOKE tag that executes the actual method we need.


   
   
]>

   
      
         
      
      
         
            metricsAdvisor
         
      
   

   
      
         FacilityService
      
      
         getHeldFacilities

The Event Bean – RemoteEventMap.cfc

This is the simple RemoteEventMap that each event creates as a bean.

In Part II – which I will hopefully finish up tomorrow – I will show implementation examples of this pattern for ColdFusion and for Flex.

ColdSpring Low-Fat Double Inner-Bean Latte

Steve Brownlee — Wed, 16 Jul 2008 14:13:41 +0000

I don’t know, when I was thinking about a name for the post, all the terms I was coming up with made me think of those coffee freaks at StarBucks ordering their custom cup o’ Joe.

Anyway, just wanted to share something that made my ColdSpring.xml file much cleaner and easier to manage/read. I use the AOP feature of the ColdSpring framework to add logging advice to my most heavily used components. This led to many, many, many beans in my config file as I had one for the gateway, one for the service and one for the proxy factory which wrapped around the service.


	
		
	



	
		
	
	
		
	
	
		
	



       
		
       
       
		
			exceptionLoggingAdvisor

Then a few months ago, I was trolling the ColdSpring discussion boards and came across a post from Barney Boisvert where he mentions that he uses anonymous inner beans when creating the AOP proxy in order to prevent the creation of the actual service component.

It sounded like a good idea, so after implementing that, it reduced the amount of bean definitions in my config file by, you guessed it, 33%.


   
      
   



   
      
         
            
         
         
            
         
         
            
         
      
   
   
      
         exceptionLoggingAdvisor

Then it hit me today. I never directly access my gateway components, since there is a method in the service component that proxies each gateway method. If I don’t use the gateway beans, I thought, why on Earth don’t I just make them inner beans of the service definition?

In the end, I’ve reduced the amount of bean definitions by, you guessed right again, 66% and now just have one bean definition for each component. Nice and clean, just the way I like it.


   
   
         
            
         
         
            
               
                  
               
            
         
         
            
         
      
   
   
      
         exceptionLoggingAdvisor

Invoking ColdSpring beans with ajaxCFC

Steve Brownlee — Tue, 20 May 2008 16:07:43 +0000

As a heavy user of Rob Gonda’s ajaxCFC library, I’ve incorporated it into almost every app I’ve written in the past two years. The only restriction that required me to write workarounds was the fact that you could only invoke ColdFusion Components directly. The thing is, I also love ColdSpring to manage dependencies and to implement my Aspect Oriented Programming components.

What I want is to be able to call my ColdSpring beans with ajaxCFC so that I can make my asynchronous calls, get serialized data back, and all the while utilizing the dependencies set up in my beans. Well, I finally got around to modifying Rob’s code to allow for this. I use the jQuery branch, so my solution currently only works for that implementation. I may try to work on the DWR version, but that’s unlikely because I don’t use it.

There are three changes to how you invoke ajaxCFC in order to work with ColdSpring beans.

The URL Attribute

Instead of the URL value being the path to your logic component, its value should be the path to the ajax.cfc component

url:'com/company/common/ajax/ajax.cfc'

The Bean Attribute

This property’s value will be the name of the ColdSpring bean you want to use.

bean: 'Facility'

The Factory Attribute

This property’s value will be the name of your ColdSpring bean factory.

factory:'application.beanFactory'

A Complete Invocation

Here’s a sample call stripped directly from one of my applications

$.AjaxCFC({
	url:'com/company/common/ajax/ajax.cfc',
	bean: 'Facility',
	factory:'application.beanFactory',
	method: 'getFacilities',
	data: { 'orderby':orderByField },
	useDefaultErrorHandler: false,
	success: function(results) {
		$('#facilitySelectContainer').html(results);
	},
	error: function(results) {
		Ext.MessageBox.alert('Error Notification', 'There was an error while loading the facilities. Please try again.')
	}
});

The Code

There are two files you need to replace.

ajax.cfc
jquery.AjaxCFC.js

Download ColdSpring-enabled ajaxCFC

ColdSpring Remote Proxies as WebServices… Whew!

Steve Brownlee — Tue, 11 Mar 2008 20:59:48 +0000

You know the word caveat, right? Well, today I learned that there are a few caveats when setting up ColdSpring remote proxy beans.

When invoking a webservice that has logically optional arguments, you still have to pass all defined arguments with the omit attribute set to yes on the tag (see Listing 1.1 below). Otherwise you’ll get the result of a Java method exception. It will look something like this – ” Web service operation “someMethod” with parameters {ARGUMENT={1}} could not be found”
When you have optional arguments in a component method that you want to access as a webservice, you have to provide a default value for each one. Otherwise, you’ll get premature end of file Axis errors (see Listing 1.2 below)
You must define the (somewhat) undocumented beanFactoryName property of ColdSpring’s RemoteFactoryBean. This will be the package name of where your ColdSpring definitions are located in the application namespace. For those using Model-Glue, this will be {app name}.framework (see Listing 1.3 below)

Listing 1.1


billGroupService = createObject("webservice", "http://localhost/webapps/charm/remote/BillingGroup.cfc?wsdl");


	
	omit="yes">
	omit="yes">
	omit="yes">

Listing 1.2


	default="" type="string" required="false" />
	default="" type="string" required="false" />
	default="" type="string" required="false" />
	default="" type="string" required="false" />

Listing 1.3


	
		
			exceptionLoggingAdvisor
			metricsAdvisor
		
	
	
		
	
	
		BillingGroup
	
	
		/webapps/charm/remote/
	
	
		charm.framework
	
	
		*