Groovy bean factory?

[Rod Johnson]

I hate unfinished business, so I've just checked it in...

[Stephen Baishya]

Rod,

Can you elaborate on why you describe writing controllers in a scripting language as "an emerging best practice"?

I'm intrigued to know the thinking behind this statement.

Regards,

Stephen Baishya

[Colin Sampaleanu]

Using a scripting language for controller logic usually leads to an increase in agility. It's faster to make and test changes while developing, and potentially easier to make changes even when the app is put into use. If the app is properly written so that heavy lifting is done by lower layers, the performance implications are not usually much worse than doing the controllers in Java...

[sethladd]

While I agree that in principle, using a scripting language can be more agile, in practice it might not be.

My main concern is that much of the refactoring I do these days is through my IDE (eclipse, in this instance). If I start coding in groovy, for instance, I'll loose all the nice refactoring support that my IDE provides. Some day, of course, I'll be able to refactor my groovy code as easy as my java code.

For now, I think keeping everything as Java is still easier. But the ability to change the code without redeploying is a huge benefit.

[Stephen Baishya]

But if, as Colin says, the "heavy lifting is done by lower layers", would you be needing to change controllers that often anyway, particularly if the controller is only dealing with some kind of facade object?

[sethladd]

Well, certainly there isn't that much code in the controllers. But what I'll miss is the ability to use the IDE to refactor. If I refactor a method's name, my groovy code won't pick it up. I'm back to search and replace days. Now, maybe the advantages of using a scripting language outweigh that, but I think losing consistent IDE functionality is a big deal.

BUT... I'll be all over it when Groovy stablizes and it's fully integrated into Eclipse.

[Stephen Baishya]

Well, certainly there isn't that much code in the controllers.

Exactly! So what would be the benefit of using a scripting language for code that is inherently resistant to change? This code wouldn't be contributing to many compile-package-deploy cycles, would it?

I'm open to those more experienced than myself convincing me, but I'm not there yet. I hate to say it, but this feels like a solution looking for a problem...