[wirebox-1.6] Any work around (except javadoc) for CF9 bug with constructor injection?

So the WireBox documentation recommends using javadoc comments as a work around for constructor injection in cfscript components. I have two questions:

  1. Is this fixed in CF10 or still a problem?

  2. Is there a different workaround? Perhaps something involving default values for the arguments? I really like cfscript components, and I really don’t like the javadoc workaround.

> Is this fixed in CF10 or still a problem?

On my local machine, constructor injection annotations appear to work on CF 10 (latest update). You do have to add the required and type attribute though which kind of makes sense so the parser knows how to parse it.

component {

function init(required any myObject inject) {
}

}

> Is there a different workaround?

Well, assuming an upgrade to CF10 or Railo is out :slight_smile: you can map your CFC in the WireBox config and declare the setter inject there.

map(“SearchService”)
.to(“model.search.SearchService”)
.initArg(name=“searchCriteria”,dsl=“provider:requestCriteria”);

Alternatively, switch to setter injection or mixin injection if you want to keep the annotations in the file and move your initialization logic to onDIComplete().

> I really like cfscript components, and I really don’t like the javadoc workaround.

What’s wrong with the javadoc style? It’s more of just another approach than a “workaround”.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

What’s wrong with it is the fact that a comment should never have behavior. It should have never been added to CF (9) in the first place.

/.02

Thanks for the reply Brad. I’ll explore those options, but since it appears to be fixed in CF10 and we are planning on upgrading “soon”, then maybe I can live with the javadoc workaround for the time being.

I’ll agree with QuackFuzed and also say that it just feels wrong to me. I have to look in two places (the comment and the arguments) to get the full understanding of the behavior of the method. It might be surprising to someone who isn’t aware that it’s even possible. And lastly, I’ve become very much in favor of minimal comments and expressive code since reading “Clean Code” and this just seems to be a step in the other direction.