With many developers these days writing web applications using popular Javascript libraries (e.g. Prototype or jQuery), many find themselves having to work with data objects in Javascript to enhance the user experience.

In a recent project, I was implementing a screen that required many popup dialog boxes, related Ajax calls, and periodic status updates to ensure a slick interface to the users without the need for any screen refreshes.

Without going into the nitty, gritty of the business reasons behind all the doo-dads I was creating, I reached a point where I needed to take ColdFusion queries and convert them to Javascript objects in order to push data from function to function.

To avoid further confusion, this function is simply a customization of the existing toScript() function available in ColdFusion (you can see I use it in my code below). What this does is allow you to customize the structure of the resulting Javascript object.

ColdFusion query to Javascript object converter

<cfcomponent displayname="QueryToObject" hint="Converts a ColdFusion query into a simple Javascript object" output="false">

   <cffunction name="convert" displayname="convert" hint="Converts a query to a Javascript object" access="public" output="true" returntype="void">
      <cfargument name="queryName" displayName="queryName" type="Query" hint="The ColdFusion query to be converted" required="true" />
      <cfargument name="objectName" displayName="objectName" type="string" hint="The name of the resulting Javascript object" required="true" />
      <cfargument name="idColumn" displayName="idColumn" type="string" hint="The unique identifier column of the query to be used in the Javascript object" required="true" />

      <cfset var local = structNew() />
      <cfset local.jsMappingStruct = StructNew() />

      <cfprocessingdirective suppresswhitespace="true">
         <script>
         <cfloop query="arguments.queryName">
            <cfloop from="1" to="#listLen(arguments.queryName.columnList)#" index="local.c">
               <cfset local.colName = listGetAt(arguments.queryName.columnList, local.c) />
               <cfset local.cell = arguments.queryName[local.colName][arguments.queryName.currentRow] />
               <cfif isDate(local.cell)>
                  <cfset local.cell = dateFormat(local.cell, "mm/dd/yyyy") />
               <cfelseif isNumeric(local.cell)>
                  <cfset local.cell = val(local.cell) />
               </cfif>
               <cfset local.jsMappingStruct[local.colName] = local.cell />
            </cfloop>

            #toScript(local.jsMappingStruct,arguments.objectName & arguments.queryName[arguments.idColumn][arguments.queryName.currentRow],true,false)#
         </cfloop>
         </script>

         <cfreturn />
      </cfprocessingdirective>
   </cffunction>

</cfcomponent>

Making the call

<cfset createObject("component", "utility.data.converters.javascript.QueryToObject").convert(steelers, "steeler.number_", "jerseyNumber") />

The results

<script>
steelers.number_43= new Object();
steelers.number_43["first_name"] = "Troy";
steelers.number_43["last_name"] = "Polamalu";
steelers.number_43["position"] = "Safety";
steelers.number_43["nfl_ranking"] = "1";
</script>

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.

<bean id="VialDetailGateway" class="charm.model.request.item.vial.VialDetailGateway">
	<constructor-arg name="transfer">
		<bean factory-bean="transfer" factory-method="getTransfer" />
	</constructor-arg>
</bean>

<bean id="VialDetailTarget" class="charm.model.request.item.vial.VialDetailService">
	<constructor-arg name="transfer">
		<bean factory-bean="transfer" factory-method="getTransfer" />
	</constructor-arg>
	<constructor-arg name="VialDetailGateway">
		<ref bean="VialDetailGateway"/>
	</constructor-arg>
	<constructor-arg name="datasource">
		<bean factory-bean="transfer" factory-method="getDatasource" />
	</constructor-arg>
</bean>

<bean id="VialDetail" class="coldspring.aop.framework.ProxyFactoryBean">
       <property name="target">
		<ref bean="VialDetailTarget" />
       </property>
       <property name="interceptorNames">
		<list>
			<value>exceptionLoggingAdvisor</value>
		</list>
       </property>
</bean>

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%.

<bean id="VialDetailGateway" class="charm.model.request.item.vial.VialDetailGateway">
   <constructor-arg name="transfer">
      <bean factory-bean="transfer" factory-method="getTransfer" />
   </constructor-arg>
</bean>

<bean id="VialDetail" class="coldspring.aop.framework.ProxyFactoryBean">
   <property name="target">
      <bean class="charm.model.request.item.vial.VialDetailService">
         <constructor-arg name="transfer">
            <bean factory-bean="transfer" factory-method="getTransfer" />
         </constructor-arg>
         <constructor-arg name="VialDetailGateway">
            <ref bean="VialDetailGateway"/>
         </constructor-arg>
         <constructor-arg name="datasource">
            <bean factory-bean="transfer" factory-method="getDatasource" />
         </constructor-arg>
      </bean>
   </property>
   <property name="interceptorNames">
      <list>
         <value>exceptionLoggingAdvisor</value>
      </list>
   </property>
</bean>

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.

<bean id="VialDetail" class="coldspring.aop.framework.ProxyFactoryBean">
   <property name="target">
   <bean class="charm.model.request.item.vial.VialDetailService">
         <constructor-arg name="transfer">
            <bean factory-bean="transfer" factory-method="getTransfer" />
         </constructor-arg>
         <constructor-arg name="VialDetailGateway">
            <bean class="charm.model.request.item.vial.VialDetailGateway">
               <constructor-arg name="transfer">
                  <bean factory-bean="transfer" factory-method="getTransfer" />
               </constructor-arg>
            </bean>
         </constructor-arg>
         <constructor-arg name="datasource">
            <bean factory-bean="transfer" factory-method="getDatasource" />
         </constructor-arg>
      </bean>
   </property>
   <property name="interceptorNames">
      <list>
         <value>exceptionLoggingAdvisor</value>
      </list>
   </property>
</bean>

Sure, I had seen the name float randomly about in my travels on the information superhighway (wow, that’s a term I haven’t heard since 1999, and don’t know why it leaked out of my brain just now), but I never took the time to investigate it until about 2 weeks ago.

One word. Dayum!

Color me impressed. I’ve been married to Model-Glue for quite some time. It does everything I need and has just enough features thrown in to make me happy 90% of the time. I’m not one to rest on my laurels, though; it ain’t in my bones. On the surface, ColdBox looks to be a much more robust framework with more development tools built in to help in “enterprisey” application development.

Of course, the one thing that always scares me when I say things like “robust” and “enterprisey application development” is performance. All those extra goodies thrown into ColdFusion application frameworks always mean some performance cost.

I’ve downloaded the code and have yet to start a large project yet, but I will admit to being excited to start trying out all the ColdBox tools and see if it can hold up against the massive amounts of data, objects and users that get thrown into my apps.

How uninformed do you have to be to consider ColdFusion a legacy language? I noticed a trackback to one of my posts about using overloaded Java methods when calling them via ColdFusion. I visited it just see what they had to say, and although it just turned out to be a aggregator post, I noticed the following sentiment.

“…Steve Brownlee explores how to use overloaded Java methods in what is considered by many a legacy language…”

What “many” is this, or is it just the author extending his own beliefs on to an unsuspecting larger group? I seriously can’t believe that any group of people who have the faintest level of skill, talent or interest in web application development consider CF to be legacy.

I subscribe to a lot of development feeds, one of which is the Model-Glue Google list. I’ve seen requests from time to time for a step by step tutorial, or demo, on using Model-Glue. Obviously, the place to start is the documentation (which I believe is admittedly in need of an update). However, during the past few months, I’ve had to give a few co-workers here a crash course in how to navigate my latest MG application.

Because of this experience, I believe I can put together a fairly well done set of blog posts, and perhaps some videos, of how I set up my application, and even go into some of the features upon which I rely heavily. Of course, it would by no means be an official review of all features; I believe only Joe Rinehart could do that.

Nonetheless, one of my strengths is being able to take “complex” processes or ideas and break them down into simple to follow steps that a beginner can follow. If you read some of my past posts, I vent often about the disease I call “Doculitis” (lite documentation). This afflicts many software people and causes them write documentation from their perspective and gloss over, or even ignore, important content because it’s been internalized and they just don’t think about it like an outsider.

So, this post is mostly a reminder, or kick in the butt, to myself to make sure I make the time to help some people out there.