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

Closed
seancorfield opened this Issue Jun 1, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@seancorfield
Member

seancorfield commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cameroncf

cameroncf Jun 1, 2016

Contributor

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

Contributor

cameroncf commented Jun 1, 2016

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

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Jun 1, 2016

Member

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.

Member

seancorfield commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Jun 1, 2016

Member

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

Member

seancorfield commented Jun 1, 2016

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

@cameroncf

This comment has been minimized.

Show comment
Hide comment
@cameroncf

cameroncf Jun 1, 2016

Contributor

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.

Contributor

cameroncf commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Jun 1, 2016

Member

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 );
}
Member

seancorfield commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cameroncf

cameroncf Jun 1, 2016

Contributor

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.

Contributor

cameroncf commented Jun 1, 2016

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.

@seancorfield seancorfield added this to the 4.0 milestone Jun 1, 2016

@seancorfield seancorfield self-assigned this Jun 1, 2016

seancorfield added a commit that referenced this issue Jun 1, 2016

seancorfield added a commit that referenced this issue Jun 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment