return getCacheBox();
Actually, there’s no getCacheBox method in ColdBoxProxy for RC1, but getController().getCacheBox() works nicely.
So basically, it all boils down to the line in ColdBoxProxy that does application[COLDBOX_APP_KEY]. That is how it “knows” where to look without actually holding a hard reference to it.
I created a singleton component called ColdBoxProvider.cfc that extends ColdBoxProxy like you showed and played around wiring it into my model. For now, I gave it the following methods: getController, getCacheBox, getPlugin, getBeanFactory
Would it make sense to be able to do mixins in your models (or decorate, or sub-class them) so that they always had those ubiquitious methods like getPlugin() and getCacheBox() like all coldbox-family components have such as handlers, interceptors, plugins, etc. Some people may never touch CB from within their model, but for those of us who do, would it make sense to just put all those methods in all the time? I don’t know-- perhaps that would be a bit heavy-handed invasion of my model but it sure is darn handy to just always have those convenience methods laying around everywhere else in my app.
Or perhaps, use cfpropery autowiring to mixin the methods I needed. I really like the wirebox concept that you described of putting a place-holder provider method in with metadata describing the fact that it needed to be replaced with an actual provider method. But honestly, if I know I’m going to need WireBox, CacheBox, and the BeanFactory plugin in my service, I’d rather continue to define that the cfproperty metadata as opposed to place-holder methods. The bottom line is, I want it to be as LITTLE code as possible to actually use these proxied objects.
This is what I have currently, which is the most convenient, but doesn’t use a provider (uses cfproperty tags for injection to variables scope)
<cfset foo = cacheBox.get(“bar”)>
This would be the next best thing: (assumes provider methods have been mixed-in somehow)
<cfset foo = getCacheBox().get(“bar”)>
This would work, but getting more cumbersome: (assumes my ColdBoxProvider has been wired into the variables scope)
<cfset foo = coldBoxProvider.getCacheManager().get(“bar”)>
You know, I could even stick with my ColdBoxProvider pattern and inject in specific provider methods directly with the “model:{name}:{method}” DSL if the method I wired simply returned a reference to the provider method I needed. That would require no more code than my second example, but would still require me to specify a cfproperty tag for each provider method I planned on using.
So, it’s really a matter of how those provider methods get there, and if you only mixin the ones you’ll need, or just slap them all in so any piece of my model has full proxied-access to ColdBox. Autowiring performance would be one concern, of course.
I think my preferred solution (with only a small amount of thought at this point in time) would be an autowiring DSL that allowed for a collection of pre-defined provider methods to be wired into your components like this:
In the above hypothetical component, I would then have access to a getCacheBox() and getWireBox() method which was a provider method for the corresponding ColdBox object.
Thanks!
~Brad