Add compatibility with WireBox

[atuttle]

Eh, anyone using WireBox is probably using ColdBox, and thus, RELAX for REST. Killing this idea until it's requested by a potential user.

[jqdurham]

With Coldspring being all but officially dead and Coldbox being broken into smaller pieces, it seems that there is a higher likelihood that Wirebox will be used in conjunction with Taffy.

[guillaume-boivin]

I'm actually using wirebox with taffy. If needed/wanted I could PR what I made to make it work.

[atuttle]

I'd be happy to consider the PR as long as it doesn't break anything else... On Feb 25, 2015 7:10 PM, "Guillaume Boivin" notifications@github.com wrote:

I'm actually using wirebox with taffy. If needed/wanted I could PR what I made to make it work.

Reply to this email directly or view it on GitHub https://github.com/atuttle/Taffy/issues/87#issuecomment-76091619.

[jqdurham]

I'd like to see the user declare the DI framework they are using instead of having Taffy figure it out. That would, of course, break things for people. Checking for "IOC" or "Coldspring" in a file name seems a bit brittle. If someone extended the Injector (or IoC.cfc or Coldspring.cfc), with a CFC with a different name, it breaks. In the case of Wirebox, the default Injector does not implement containsBean and getBean, so simply extending it and creating those methods would have made it easier to adapt.

I'd also just be happy only using the internal DI factory if it would read metadata from parent resources and inject dependencies directly into the variables scope.

I'm very grateful for Taffy, so please don't take my comments as criticisms. They were merely suggestions. Cheers.

Jason Durham

On Thu, Feb 26, 2015 at 7:07 AM, Adam Tuttle notifications@github.com wrote:

I'd be happy to consider the PR as long as it doesn't break anything else... On Feb 25, 2015 7:10 PM, "Guillaume Boivin" notifications@github.com wrote:

I'm actually using wirebox with taffy. If needed/wanted I could PR what I made to make it work.

Reply to this email directly or view it on GitHub https://github.com/atuttle/Taffy/issues/87#issuecomment-76091619.

— Reply to this email directly or view it on GitHub https://github.com/atuttle/Taffy/issues/87#issuecomment-76174826.

[guillaume-boivin]

I totally agree that checking stuff in the cfc's metadata is less than great and prone to become a big cfif chain of esoteric checks.

The ideal solution I think would be to get an interface in there for clients to implement and thus make available whatever DI they may need.

Probably, just to be backward compatible, have a fallback to the "old" way of checking what the DI is (cfc's metadata analysis).

[atuttle]

I'd be happy to add an interface for the sake of compliance checking, but I don't think it's realistic to expect all (compliant) DI frameworks to add implements="taffy.core.IFactory" to their distributions, because anyone without Taffy installed would get errors (right?).

That said, once we do have an interface, it would be relatively easy to send various projects each a pull request that adds functions (or aliases) as needed to comply with the interface.

[guillaume-boivin]

I was more thinking of this kind of interface :

<cfinterface>
    <cffunction name="getBeanList" output="false" access="public" returntype="string" hint="returns a list of bean names that the external factory can provide and that are useful to Taffy ( should be beans that extends taffy.core.resource)"></cffunction>
</cfinterface>

The external factory would have to implement it, so no need to put the burden of this on the DI frameworks, just the client using taffy and needing an external factory

That way, we could provide default implementations for different DI frameworks and simplify core/api.cfc greatly by modifying https://github.com/atuttle/Taffy/blob/master/core/api.cfc#L1127-1168 to just call getBeanList() from the external factory implementing this interface.

[guillaume-boivin]

Made a quick and dirty working example of what I'm talking about : https://github.com/guillaume-boivin/Taffy/tree/%2387

[atuttle]

I like the changes in your example, but I worry that it's just a little too complex for some users that may want to use an external framework like DI/1. People don't always get our concept of (de)serializer classes, and this seems even a step above that.

That said, I guess this is not much different from things as they exist today (you'll need an intermediate adapter class for any external factory other than ColdSpring). I'm not crazy about breaking our existing out-of-the-box ColdSpring compatibility, but otherwise this seems fine.

[guillaume-boivin]

"I worry that it's just a little too complex for some users that may want to use an external framework like DI/1"

We could provide default implementations of adapters for the most popular DI frameworks and leave the rest for others to contribute. That way the complexity thing gets out of the way for most use cases.

"I'm not crazy about breaking our existing out-of-the-box ColdSpring compatibility"

It's a quick and dirty example, so if we say "let's do this" I would redo what I made to be backward compatible with what was there before.

[atuttle]

Fair enough. I guess we just need documentation on what's required for out-of-box compatibility (e.g. path to framework), and how to modify the adapters if they can't change their framework paths.

[smcguire36]

My company's app is based on Fusebox 5.5 but we also started using Wirebox now. It would take too much to migrate over to Coldbox. I have started developing an api using taffy and would LOVE to use Wirebox with it. Is it possible to just create a wrapper CFC that would implement the taffy DI factory interface but internally makes calls to Wirebox with whatever Wirebox needs?