So are you saying that the inject=“coldbox:ioc” and inject=“coldbox:ioc:nameHere” have been completely depricated?
~Brad
no, no no,
Let me start again, and I really really need your input
Before, the ioc plugin would call on the beanFactory’s autowire method after a bean was retrieved from an ioc framework (coldspring,lightwire). This was a hack to allow for cfproperty annotations to be picked up from coldspring/lightwire beans.
My grudge here is that obviously this has promoted the usage of both an ioc container and the autowiring of wirebox, thus having 2 DI engines in place for domain objects, which I think that this is not good.
Like Jason mentioned, he has a service object, which is managed by coldspring, and now it also has dependencies that it needs wired in by wirebox also. My debate here is, pick a DI engine. Either you do all your management in coldspring/lightwire, or you use wirebox.
None of the tags are deprecated or anything, the only difference, is that the new IOC plugin does not call autowire after a managed bean is requested from an ioc container.
Now, the question is, who is in favor of allowing this criss cross of DI engines and who is in favor of separation?
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
This is just opinion, but I am in favor of letting them use both. Is it the frameworks job to force them into a decision on which DI framework to use and not allow them to mix? Maybe they are using both on purpose. (They like the way this DI framework does this and they like the way the other DI framework does that).
Best practice probably indicates that using one DI framework is best and that more than one introduces overhead, but under the pre-RC1 version, there are more options to do interesting things combining your DI framework of choice and Wirebox. But that was before Wirebox became a full-fledged DI option.
I can see the reasoning for the switch though.
That’s my two cents, which is probably worth about two cents.
Interested in others opinions.
Curt Gratz
Computer Know How
The biggest problem I have with allowing them to be mixed is that
people didn't realize that they were mixing them. I know that I
certainly didn't when I first started messing with it and didn't quite
understand what Coldspring was doing, what Coldbox was doing and what
was some weird combination of the two. When I finally put Coldspring
aside and came to grips with the DI baked into CB (which is now called
Wirebox), things became a lot more clear and simple.
When you don't understand how everything is working together you have
a much greater liklihood of unintended side effects and debugging
becomes much more difficult, as does the process of the community
helping you. You do some Google searches and see one person putting
these settings into Coldbox.cfc and another page that is doing these
other annotations on their components and you just start trying to put
whatever you can in in hopes that *something* will work. This ends up
being a tangled, gnarly mess.
If we say "Pick a DI Framework" and have clearer separation between
the various frameworks, then it makes it easier to say, "If you chose
DI Framework A, here is what you need to do. If you've chosen B, here
is what you need to do".
Cheers,
Judah
Ok, maybe another happy medium is to have the clear separation between the IOC plugin and DI, but add an interception point of when an object is retrieved from the ioc container. This way, the developer can have the choice of doing whatever they want with the retrieved object.
Maybe called: “afterIOCBeanRetrieval, afterIOCBeanCreated, ideas”?
Thoughts? Comments?
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Here's a question that might shed some light on what is best to do
that I've never completely understood myself:
What problems do Coldspring and Lightwire solve that Wirebox does not?
Why would you use those instead of Wirebox? Did Wirebox make decisions
to not do some things that Coldspring and/or Lightwire do that
developers might want to take advantage of?
On the flip side, what things do you get using Wirebox that you don't
with Coldspring and Lightwire (I'm guessing Autowiring here, but I may
be wrong and there may be others)?
If we can clearly articulate the differences between the projects then
we might be able to come up with a solid way to figure out how to
allow developers to take advantage of the best bits of all of them.
Cheers,
Judah
Is this compromise merely based upon principle or is there some additional benefit that I can’t see? As a Coldbox fanboy, I would be disappointed to learn that a feature was removed from the Coldbox core simply to give credit to a tool spinoff.
Jason Durham
Even if we compare features today… what about tomorrow? What about when CS2.0 is released? Why would anyone own a Mac when a PC can do nearly everything a Mac can?
Jason Durham
This wasn't meant as a "why bother with Coldspring?" sort of
discussion, not meant as a dig at all. Rather I wanted to see what the
use cases are for the different products. What are the things that
would make a developer want to use *both* Coldspring and Wirebox? If
we can understand those differences and their cases, we can figure out
the best way to make them gracefully coexist.
Judah
Luis,
Would you have the framework run autowire on those new interception points? Or would the developer have to create an interceptor and have the custom interceptor autowire. I can’t see many people using the later as it is certainly easier just to have the DI framework do that work for you.
I like Judah’s line of thinking. Before I switched to purely using Wirebox, I know I would have coldspring wire together my model objects, but use ColdBox autowiring to inject any coldbox related functionality (maybe a plugin or setting) as I found that easy enough to do. But what are the use cases for using both outside of convenience. I, like Judah, didn’t even give it a thought that I was doing both at first as I didn’t really view ColdBox as doing DI for me, but really just a perception issue.
I also am a fan of convenience. 
Curt Gratz
Computer Know How
The most obvious use case is… there are legacy apps written on previously supported methodologies.
Jason Durham
Outside of backwards capability for existing apps that use both -- not
an insignificant upgrade barrier if there are a lot of apps like that
and the capability is gone -- I'm with Judah. We really need to
understand where the capabilities of the different DI engines diverge.
Without that, we don't really know what rational (as opposed to
unwitting) use of multiple engines would look like, so it's hard to
think about how to make that simple, elegant, and powerful.
Re circular dependencies, that's a tricky bit of DI engine design. I
thought lightwire handled that, but only if you used setter injection
not constructor, but though I use it in one major app, I've never had
a circular use case. I've been using ColdBox DI since I started
exploring ColdBox, and have no circular cases there either, but I do
remember seeing parameters intended to let you break a circular chain
constructively if you need to.
Bottom line is that it'd be great if someone who knows all three
engines well could take the time to post something from that vantage
point; it's certainly not me.
Dave
I will post a more un depth reviewsoon. As for jasons problem I really like what curt wroteabout convenience and ease of use. Anyways I will ads it again andmakenote in the docs about being careful ofmixing wiring methodologies. Again in my opinion I would use one di engine in my app.
Thanks for such great feedback guys and helping us build better software