RE: [coldbox:8464] Re: WireBox notes

I’ll take a look.

~Brad

Ok, so I took a look at locateScopedSelf and I don't think it's doing
anything other than pulling itself up by its own bootstraps. Asking
the injector to find itself doesn't work if you have to still place a
hard reference to the injector itself in the first place. You can't
use the injector to find the injector (that might create a black hole
in the Internet). We need a stand-alone object that contains the
information necessary to locate the injector for us.

I would recommend enhancing the Provider object to not only be able to
provide a dependency, but also be able to provide WireBox for its own
use as well a CFC with provider methods like so:

Change the Provider object to have a getWireBox method.
Instead of constructing the Provider with the actual injector, pass in
the scopeRegistration struct.
Also, have the provider create and store an instance of the
ScopeStorage facade.

provider.getWireBox() would basically be the code you put in
locateScopedSelf (except don't re-create the scopeStorage object every
time to avoid unnecessary object instantiation-- I assume scopeStorage
is thread-safe)

When the get() method is called on the provider, change this:
<cfreturn
instance.injector.locateScopedSelf().getInstance( instance.name )>
to this:
<cfreturn this.getWireBox().getInstance( instance.name )>

Now, in the injector's processProviderMethods function, change this:
arguments.targetObject.$wirebox = this;
to set in a new instance of a Provider object instead that has been
constructed with the scope registration information

Then, bulder.buildProviderMixer() would change from:
return this.$wirebox.locateScopedSelf().getInstance( this.
$wireboxProviders[ getFunctionCalledName() ] );
to
return this.$wirebox.getWireBox().getInstance( this.
$wireboxProviders[ getFunctionCalledName() ] );
since $wirebox is not the injector any more but an instance of a
provider which can find the injector for us as neccessary.

In this way we have broken the hard reference between our provider
objects/CFC's containing provider methods and the WireBox injector and
have replaced it with the stand-alone provider object which is now
smart enough to use the scopeRegistration information along with the
ScopeStorage facade to find WireBox as necessary.

It's still just in my head right now, but I'm 96.7% sure it will
work. Do you want me to cook it up and commit it to my fork for you
to look at?

Testing should be pretty easy-- create a provider for a "default"
CacheBox-scoped object and persist the provider somewhere like session
or application and fwreinit. The provider still needs to work after
the fwreinit and find the newly reloaded WireBox injector (and
CacheBox instance) and not have any references to the old ones.

Thanks!

~Brad

Ok, so I took a look at locateScopedSelf and I don’t think it’s doing
anything other than pulling itself up by its own bootstraps. Asking
the injector to find itself doesn’t work if you have to still place a
hard reference to the injector itself in the first place. You can’t
use the injector to find the injector (that might create a black hole
in the Internet). We need a stand-alone object that contains the
information necessary to locate the injector for us.

Hi Brad, however, you are missing the link here. The blueprint of the injector with all of its instance data will be avialable to the provided object. What is not is the linkages to whatever expired on scope like coldbox, cachebox etc. However, the injector still has relevant data of WHERE it was stored. So by accessing that I can then go directly to that scope (application) by default, and retrieve the latest instance of itself that is valid and running. Try it. It worked in all my scenarios where session outlived the application scope or a reinit was issued.

What you are describing below is exactly the same thing except just going to the scope storage directly. Try it, you will see what I mean. However, I think that you have a point on the recreation of the scope storage. So I will update the code to create it on init and then reuse it. However, what you propose below is the same except going directly to the scope registration. Anyways, try it, you will see what I mean.

By the way, I really appreciate your comments and suggestsions!! I really think that WireBox has A LOT of things that came from you, so please please keep on helping out!!

I agree, some really great thoughts and catches I didn’t have looking through it.

Curt