Provide a FW/1 facade to allow out-of-band requests to access some functions

[seancorfield]

This comes out of discussions in #438 around a standardized way for non-framework code, called during a FW/1 request, to be able to call into parts of FW/1 (to get the bean factory etc).

The most feasible approach would seem to be for FW/1 to stash a reference to itself in a "publicly documented" request scope variable for such facades to be able to access?

[cameroncf]

Copying this gist over from #438 as a first run at some ideas:
https://gist.github.com/cameroncf/45c6220faa6d64ff08b6c8ee1c45217c

[seancorfield]

As noted, I'd probably put a reference to "the whole FW/1" rather than just the application key. That way any facades only need to know about the request scope variable, not how to use it to reach into application scope etc.

[seancorfield]

That would allow access to subsystem bean factories and any other part of the FW/1 API you might want.

[cameroncf]

Is there value in making it a request variable vs something like FrameworkOneFacade.cfc? I sort of like the idea that I know I am safe using FrameworkOneFacade regardless of how things are stored internally (app score, request scope, etc). Once you declare that special request scope variable people will start coupling into it in their apps and it may become harder to change in the future.

Other questions I ponder - if you are making "the whole FW/1" available, then what happens about lifecycle events like before()? Did they fire yet? Will people need to know this? The beanfactory is a less complex animal then "the whole FW/1" but you know way more about that than I do.

[seancorfield]

I would provide framework.facade as the official way to access FW/1 out-of-band. Your comment makes me realize that I don't need to document the request variable being used, thank you.

As for lifecycle events, that's definitely "caveat programmer" if you're doing stuff out of band. In the use case of #438 you would be accessing the facade as a normal part of the request lifecycle anyway -- this would just provide a bridge to access certain FW/1 API calls in places where it would otherwise be extremely difficult to do so:

function getService( serviceName ) {
    return new framework.facade().getBeanFactory().getBean( serviceName );
}

[cameroncf]

I do like that approach. Seems to basically satisfy the core need that I personally have when I am working with ORM.

The framework.facade would probably want to do some very basic tests so it can throw an error if it detects that FW/1 hasn't been initialized yet - but otherwise it's just there to be smart about where FW/1 is kept and provide access to it without the developer worrying about any of that.