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>

Proofs of the adage, “truth is stranger than fictiion”….

Town Outlaws Stripperobics
Religious cult irate over magic cracker

And from the world of code, I found this ColdFusion gem the other day. I’m not really sure what this guy was doing.

<cffunction name="getStatuses" access="remote" returntype="query">
	<cfscript>
	qStatuses = QueryNew("");
	QueryAddRow(qStatuses, 1);
	</cfscript>

	<cfquery name="qStatuses" dbtype="query">
		select 'Held' label, 'HELD' data from qStatuses union  all
		select 'Cancelled' label, 'CANCEL' data from qStatuses union all
		select 'Cancel Requested' label, 'CAN-REQ' data from qStatuses union all
		select 'Released' label, 'RELEASED' data from qStatuses union all
		select 'Release Requested' label, 'REL-REQ' data from qStatuses
	</cfquery>

	<cfreturn qStatuses>
</cffunction>

Oh wait, he did it so he could build a Javascript array string… from the query… instead of just… hard-coding it?

<cffunction name="getStatusesJS"  access="remote" returntype="any">
	<cftry>
		<cfset qStatuses = this.getStatuses()>

		<cfset js = "var _statuses = {};">
		<cfoutput query="qStatuses">
			<cfset js = js & "_statuses['#DATA#'] = {label:'#jsstringformat(LABEL)#',data:'#DATA#'};">
		</cfoutput>

		<cfreturn js>
    <cfcatch type="database">
   		<cfrethrow>
    </cfcatch>
    </cftry>
</cffunction>

I suppose it is far more pedestrian and not very “OOPy” to just do…

<cfset jsArray = ArrayNew(1) />
<cfset ArrayAppend(jsArray, "var _statuses = {};") />
<cfset ArrayAppend(jsArray, "_statuses['HELD'] = {label:'Held',data:'HELD'};") />
<cfset ArrayAppend(jsArray, "_statuses['CANCEL'] = {label:'Cancelled',data:'CANCEL'};") />
<cfset ArrayAppend(jsArray, "_statuses['CAN-REQ'] = {label:'Cancel Requested',data:'CAN-REQ'};") />
<cfset ArrayAppend(jsArray, "_statuses['RELEASED'] = {label:'Released',data:'RELEASED'};") />
<cfset ArrayAppend(jsArray, "_statuses['REL-REQ'] = {label:'Release Requested',data:'REL-REQ'};") />
<cfset jsString = ArrayToList(jsArray, " ") />

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.

For those who may be new to the Eclipse IDE, here’s a list of common shortcuts I use to help me access resources and find code quickly.

Open Resource (CTRL+SHIFT+R)

This shortcut opens a dialog where you can type in the first few letters of a filename you want to open and a list of matching filenames show up beneath. Alternatively, you can highlight a filename in your code, and it will be pre-populated in the dialog search field.

Working Sets

If you work in an environment with many projects going on at once, your Navigator window can quickly get cluttered and confusing. The best way around this is working sets. You can group 1 or more projects into a working set that, when chosen, will only show those projects in the Navigator.

Outline View

Have large XML or Javascript files? Having a hard time finding methods or elements in the haze of code? The Outline view will save you plenty of time.

Quick Switch (CTRL+E)

Whether you’re working on fixing a system-wide bug, or making style changes to many pages in your site, sometimes you just can’t help having 10 files open at one time. Since Eclipse will only show 6 of those in the tabs, you can easily switch to any of the files with this handy shortcut.

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.