OK, I forked your repo, fixed your aspect and config so it all works, and then submitted a pull request which is actually a rather convenient way to describe what to change
So, to answer your questions:
Why does message box error when injected in the aspect? This isn’t really a “race condition” per se (in that it works sometimes, but not always)-- it’s more of a catch 22 with the order that the framework loads up. One of the first things that the framework does is load its configuration. This includes, the location of flash storage as well as your AOP aspects. The request service sets the flash storage to a “0” when it is created, and then as soon as the configuration is finished loading it actually sets it. When the messageBox plugin is created it gets the flash storage object from the request service. The problem is that when you inject the messageBox plugin into an aspect, you force it to get the flash object prior to its creation. This is order it happens in:
- requestService is created by the framework (with a default value of “0” for the flash object)
- Configuration is loaded
- AOP aspect is created and injected with MessageBox plugin which prematurely grabs the flash object form the request service
- RequestService uses config to create the real flash object, but it is too late as the messageBox plugin has already been created.
- Aspect fires when unsecure URL is hit, but messageBox errors because it has a bad flash obejct
In my pull request, you can see the provider works because it defers the creation of the messageBox plugin in step 3 until after step 5 when the aspect is actually used. The only way I can think of around this would be to stop storing the flash object directly in the messagBox plugin and instead create a getFash() method that hits the request service every time.
The second question was why does setNextEvent not work in an aspect. My previous speculation that the method in the aspect is mixed in and therefore run out of context was wrong so please forget I ever said it There is a dynamically-created mixed inject into the target object, but the actual invokeMethod method still lives inside of the aspect CFC and has access to anything defined within it. Your belief that the aspect should inherit methods from the framework supertype is wrong. Aspects are treated like part of your models and receive no virtual inheritance like interceptors do. That would be possible, but we would need to create a base class for aspects and pass in a controller reference when creating them like interceptors get. Luis would have to chime in on whether or not aspects should be considered a “framework” object or not, but I think there’s a valid argument to say it shouldn’t be.
That said, if you want to call setNextEvent in an aspect, then you’d need to do the same thing you do in a model, which is inject a controller reference and call controller.setNextEvent(). You can see, that’s what I did in my code.
Now, the messageBox plugin works AND the setNextEvent also works. I added getPlugin(“MessageBox”).renderIt() to your layout so you could see the message.
ColdBox Platform Evangelist
Ortus Solutions, Corp