By barneyb on June 26, 2008
Rob Pilic found a couple local variables that I (gasp!) forgot to var scope in the DSL implementations while he was troubleshooting some concurrency issues. There was one in each file, though totally unrelated. I've applied his patch to Subversion and updated the demo install (though it won't matter, because it doesn't share instances).
Posted in development, tools
By barneyb on June 23, 2008
I occasionally get questions about licensing my code for inclusion in other projects. I thought I'd make a blanket statement that all my code can be assumed under the Apache 2 license unless otherwise indicated. For where it's not explicit, just drop me a line if you need formal licensing, and I'd be happy to set it up. Most of what I do is rather informally released (i.e. put in public Subversion), so I usually don't take the time.
Posted in development, meta
By barneyb on June 23, 2008
I just got a JIRA notice that Michael fixed Railo so that arrays and structs implement java.util.List and java.util.Map respectively. This is great news, because it means it's now possible to pass nested arrays and structs to Java APIs without having to manually rewrap them. From the ticket, it looks like the fix will be available in the next 3.0 beta, though I don't know when that's due out.
On the compatibility front, this means that the three major Java-based CFML runtimes (ColdFusion, Railo, and Open BlueDragon) all have compatible arrays and structs, which is a good thing if you need to write portable code that leverages underlying Java APIs.
Posted in cfml, railo
By barneyb on June 20, 2008
So As I said in my last post, there's been a lot of talk about integrating CFML apps with other bits. I've been playing with Groovy and Grails a fair amount (duh), as well has having a lot of conversations about it. I've been trying to figure out what the best use case is for the different pieces, and here are what I see as the main alternatives:
- Use Grails for your whole app stack
- Use Grails for your lower stack, and CFML for the view implementation (instead of GST).
- Use CFML for your web layer, and Groovy (maybe via Grails, maybe via plain Spring) for the lower layers, including GORM/Hibernate for persistence
- Use CFML for the web and service layers, and using Groovy w/ GORM/Hibernate for the data layer.
- Use CFML for the whole thing, and just stick in a bit of Groovy as needed, maybe with a partially GORM/Hibernate-persisted data model.
So what's the right one? My initial feeling was option three, but after a bunch more talking and thinking, I'm now leaning towards number 4. The service layer doesn't suffer from the same performance issues related to CFC instantiation that the data layer does. So using CFML (w/ ColdSpring) has few real downsides for the service layer, but it has definite upsides because you can use CFML within the layer. Better, you still get the huge benefit of Hibernate and POJOs in the data layer, which is where CF really has a lot of problems.
Interesting times to be sure. Hopefully when I get back from the conference I'll have more time to write some code and really dig in.
Posted in cfml, groovy
By barneyb on June 19, 2008
As is typically the case, CFUNITED has a pair of themes. There's the conference theme, which, as always, is helping CF coders become more empowered by learning about new things (OO, using CFCs, learning frameworks, etc.), and then there's the "backtheme". This year it's all don't use only CF. Adobe's integrating Hibernate into CF9, Railo is preaching the benefits of the JBoss platform (clustering, caching, Hibernate, etc.), Groovy has a lot of lovers, and Grails (which is Spring and Hibernate for Groovy) does to.
The integration of Hibernate all over the place is very exciting. CF-based ORM tools suck, frankly. Which isn't to belittle Mark or Doug in any way, they've done a fantastic job, it's problems with CF itself that are the issue. With Railo's "CFC is a class" implementation, Hibernate is directly applicable. With CF's crazy "a CFC is a bunch of classes in a Map" implementation, I'm not sure how Adobe's going to get it to work. I'm very much hoping they fix the core issue (which would almost certainly give some nice performance benefits as well) instead of bastardizing Hibernate to get it to work, but we'll see.
Posted in bluedragon, cfml, coldfusion, development, grails, groovy, personal, railo
By barneyb on June 16, 2008
Here I am just out of the shower, sitting on the back patio with bare feet and a t-shirt, sunset behind the trees, listening to the babbling fountain and some Leaves Eyes', and finishing up a bag of Mother's Circus Animal cookies. If only I had a fruity drink with a little umbrella in it…
Posted in random
By barneyb on June 16, 2008
Tomorrow morning I hop on a plane to CFUNITED in Washington DC. Four days of learning, chatting, getting far too little sleep, and generally being a programmer geek 24 hours a day. Even better, Joshua and Koen (two coworkers) are coming as well. It's been a hellish past few weeks at Mentor, and getting a little decompression will be a welcome change.
Posted in random
By barneyb on June 14, 2008
My last post about Comparators via CF Groovy was simplistic in nature, but the underlying concept is incredibly powerful. Here's a similar snippet (from the demo app), this time using a Comparator class:
<g:script>
Collections.sort(variables.a, new ReverseDateKeyComparator())
</g:script>
So what do we have here? Why it's a snippet of Java embedded directly in your CFML page, and it gets dynamically compiled and executed just like the CFML. Let me say that again: it's a snippet of Java embedded directly in your CFML page. It's even better than that, though, because it's Groovy, which is Java plus a whole lot more.
In addition to the scriptlet functionality, CF Groovy provides a classloading framework for Groovy scripts and classes, in addition to the ones provided by the CFML runtime and the JVM. You can define an extra Groovy classpath for your scriptlets like this:
<g:setPath path="#expandPath('/groovy')#,#expandPath('/packages')#" />
There's no way to tell how the ReverseDateKeyComparator class in the first example is implemented, but it happens to be a Groovy class that I've added to the classpath with the <g:setPath> tag. That class, just like the scriptlet, is dynamically compiled and executed just like the CFML. This is also very powerful, because it eliminates the compile/build/deploy cycle that is usually required for Java code in a JEE environment.
Combining these two, you can use <g:script> to execute arbitrary scripts from the Groovy classpath, instead of inlining them:
<g:script name="myScript.groovy" />
This lets you reuse scripts across CFML pages, as well as reusing classes between scripts.
I've added CF Groovy to my Projects page, so that's the place for the latest info, as well as some documentation and the all-important Subversion information.
Posted in cfml, groovy, java, tools
By barneyb on June 13, 2008
I don't know about anyone else, but wanting to create little ad hoc Java classes in my CF apps in a common occurrence for me. With my CF Groovy project, it's both possible and very easy. No Java, no compiling, no classloading hacks.
Here's a simple example. I'm going to create an array of structs and then sort the array based on a specific field value (the 'date' field) of the structs. Doing this in CF usually means making a lookup struct, sorting that, and then rebuilding the array (but only if you have unique values), or converting to a query and using QofQ to do it. Both have serious drawbacks, as well as being very circuitous/obscuring.
First the array construction (six items, each with 'letter' and 'date' fields, holding what you'd expect). Nothing very interesting here.
<cfscript>
a = [];
month = createDate(year(now()), month(now()), 1);
for (i = 1; i LTE 6; i = i + 1) {
s = {
letter = chr(65 + randRange(0, 25)),
date = dateAdd("d", randRange(0, 30), month)
};
arrayAppend(a, s);
}
</cfscript>
Now, using the <g:script> tag from CF Groovy, we'll sort it by date using a java.util.Comparator:
<g:script>
Collections.sort(variables.a, {o1, o2 ->
o1.date.compareTo(o2.date)
} as Comparator)
</g:script>
If you want to compare based on the letter, just change the two ".date" references to ".letter". You can, of course, make the comparator as complicated as you'd like, including referencing other Groovy classes through CF Groovy's classloading, or other Java classes on your classpath.
You can see it in action at the demo page, or get the full source from Subversion at https://ssl.barneyb.com/svn/barneyb/cfgroovy/trunk/demo/.
Posted in cfml, development, groovy
By barneyb on June 9, 2008
I'm pleased to say that I'll be speaking at CFDevCon this September over in Brighton, England. The conference should be a great one: lots of great speakers, lots of great topics, and what should be a great location. They also announced last Thursday that early bird pricing has been extended to the end of the month, so if you haven't got a ticket, now's a good time.
I'll be presenting on two topics at the conference: AOP for ColdFusion with ColdSpring, and leveraging Java from ColdFusion. Both really ought to be "CFML" instead of "ColdFusion"; I expect I'll be using either Open BlueDragon or Railo for the presos, but time will tell.
In related news, I've since learned that the lighthouse in my blog header is about 20 miles (I'm from the US, what do you want?) from Brighton. We'll see if I can swing a trip over there to get a picture of me with it. It's kind of humorous that I'd been using that photo for well over four years without knowing where it was, and now I'm going to be flying half way around the world and end up 20 miles from it.
Posted in personal