I'm only using CF Groovy and Hibernate for personal projects, where I, surprise, work alone. ;) The framework was developed solely on personal time as well, and with basically zero hope of any at-work integration, at least where I work now.

At work we do a lot of interfacing with Java, and the CF Groovy integration would be very valuable, but the boss doesn't want to adopt any Groovy. So we hack together all kinds of interesting stuff in CF, and occasionally shell out for some real Java (and all the compile, restart, etc. fun it brings). One really good example is getting a java.util.List of content objects back from the CMS and wanting to sort the list. You need a Comparator. So instead of dropping a <g:script> tag with a one-line Comparator in there, we build a Java class, compile it, create a JAR, add it to the application's classpath, restart the container, and then see if it works. It's retarded.

So we use CF (RAD, dynamic, no compile, limited in scope) and Java (non-RAD, static, compile, virtually unlimited). Groovy (RAD, dynamic, no compile, virtually unlimited), on the other hand, is off the table. It's a silly political distinction, but such is life. But more to your point, I work on a team of 11, 7 of which are full-time developers (the rest are operational support people who write a lot of the view layer based on customer needs, and generally help the customers use the applications), and we all write both CF and Java. So Groovy would not be anything of a stretch from a technical side.

On smaller teams with really agile people and leadership, this sounds great. In larger IT departments with the whole gamut of skills… yikes.

Again, I'm asking only because I'm curious if you're yet in a position where you're trying to introduce this and I'm wondering how you're doing so, or if this is just a one-man-show at this point.

Thanks!

marc

There are performance implications, but I guess you have to pay a price somewhere if you want to hook CF into it.

With CFCProxy, you'll have to invoke some facade CFC that then delegates back to the "real" CFC instance, right? It's been a while, but I don't recall being able to create a proxy for an existing instance. I supposed if it's all generated it's not as much of a deal, but there's still performance implications.

I'd love to see a good way to write more with Groovy, but not lose the CFML nature of the application. Both have great strengths, but CF rather bastardized the many languages/one JVM model, which makes it hard. To be fair, Groovy's done some of the same thing with it's MetaClass infrastructure, but if you don't use it (i.e. declare normal methods, fields, etc.) your Groovy objects are "normal" Java instances at runtime. With CF you don't have that option.

What would be very handy is some transparent means to enable you to write your services in CFCs, but keep your business objects in Java/Groovy, and still be able to inject those CF CFCs into your Groovy/Java business objects, (Hopefully) in a very seamless manner, through the use of CFCProxy.

I haven't worked out all the details, but that way you could keep the RAD nature of CF, but still be able to push it into your Business Objects (much like I do now in CF)

Because I'm still figuring out where everything best fits. ;) Writing whole classes in Groovy precludes the use of CFML, which is a significant ramification. CFMAIL's really handy compared to managing a JavaMail interface manually, for example. Much of what I'm using Groovy for is more akin to using CFSCRIPT – an alternate/simpler/richer syntax for non-CFML-specific programming tasks. Even simply things like ["one", "two", "three"].each{ /* do something */ } can be quite handy, and with the lack of overhead entering and leaving the Groovy runtime, there's little reason not to use that stuff, even if it wasn't the real point of the implementation. Another problem is that while CF can call Groovy, Groovy can't call CF. So once you cross into Groovy-land, you're stuck there.

The "Groovy logic" in the service and controller tiers is really service and controller logic. It's not that I'm spreading my business logic up the levels, more just that I'm using it in places I hadn't really expected to initially. When I was first building the whole framework, I was really envisioning a all-CF web/controller layer, a CFC-with-embedded-Groovy service layer, and then a Groovy-based persistence layer. But in practice I'm finding CF-with-embedded-Groovy web/controller, CFC service layer, and Groovy-based persistence.

At this point, I don't think implementing the service layer in Groovy is the right choice. Sure, I'm using bits of Groovy (both snippets and classes) to accomplish things, but the apps are still CFML apps, and I don't want that to change. If I were doing more of a JEE-style of development, using Spring, Hibernate, and Groovy together to build backends would definitely be something to consider, but at this point, I want my CFML. I'm lazy, I don't always have a full IDE (emacs over SSH, anyone?), and the "problems" that CFML has aren't nearly as big a deal with Groovy for the entities. If I were working on "real" projects where there was budget, timelines, resources, etc., I'd undoubtedly make different decisions.

Like you, I'm liking Groovy more and more (and I'm only halfway through the Groovy Recipes book!).