FW/1 - Framework One - is a lightweight, convention over configuration, MVC application framework for ColdFusion / CFML.
[clockworkrebel, cfml] I'm new to this framework and so my understanding of how this is supposed to work is probably not quite right
[Sean Corfield, cfml] @jtreher I was looking over the handful of open issues in the FW/1 GitHub repo and noticed this which sounds a lot like your issue framework-one/fw1#423
[Ross, cfml] what’s the approved method of accessing the subsystem bean within my other one?
[Ross, cfml] (the answer can be ’do what you’re doing in a service, if need be)
[Ross, cfml] the scenario is that I have a client bean where I’m calculating an ‘age class’, e.g. ‘18-25’, based on the client’s DOB
[Ross, cfml] the list of age classes are a list in my lookups table, so lookup bean
[Ross, cfml] (lookups is a subsystem)
[jtreher, cfml] I'm just reporting back that we have not been able to resolve our issues with reloading the application under load. We are currently reverting everything and are going to try to upgrade just DI/1 to see how it fares there to help isolate the issue. It totally seems related to the legacy subsystems.
[Ross, cfml] @aliaspooryorik no
[Ross, cfml] at least, that’s not an option in this instance
[Ross, cfml] If I dip down to the application yes, but id rather not do that obviously
[Carl Von Stetten, cfml] Can you pass
fw as a property into the "client" bean?
[Carl Von Stetten, cfml] Admittedly, this would feel really dirty, so the service approach would probably be better.
[Carl Von Stetten, cfml] I've done this in some controllers where I need to grab a bean from another subsystem.
[Sean Corfield, cfml] @jtreher One thing you might try is preloading the subsystems in
setupApplication(): for ( s in ["list", "of", "subsystems"] ) setupSubsystem( s ); That should solve the lazy-loading under load issue (you may need an application scope lock around that tho').
[Sean Corfield, cfml] Kinda brute force but worth a try.
[Sean Corfield, cfml] @salted If one of your subsystems has a dependency on a bean in another subsystem, that's definitely something you need to correct -- by moving the bean to the parent (main) app context. Cross-subsystem dependencies indicate a broken design, sorry.
[Ross, cfml] We use our subsystems as modules essentially so it's not an option in this case, but thanks for the pointer I will bring that up
[Kevin Miller, cfml] this may have already been covered but what about a main service that can marshal requests for beans generically to act as a bridge for all areas of the app to leverage
[John Whish, cfml] JSON can be as simple as
false or "hello" so they would fail as well.
[Kannan.P, cfml] Is any having basic idea about FW1 with Vue js ? If yes could you please send some reference link to me ? Thank in advance.
[John Whish, cfml] Have a read of http://framework-one.github.io/documentation/4.2/developing-applications.html#controllers-for-rest-apis
[github-fw1]
[framework-one/fw1] Pull request closed: framework-one/fw1#504 by seancorfield
[github-fw1]
[fw1:develop] 2 new commits by Matthew J Clemente and 1 other
[Sean Corfield, cfml] @mjclemente ++ Thank you for the issue and PR!
[watney, cfml] `@seancorfield gives karma to @mjclemente. They now have 13 karma. #38 overall.`
[Matthew Clemente, cfml] Thanks @seancorfield!
[Carl Von Stetten, cfml] Having major issues trying to use FW/1 4.2 as a REST API backend for an Angular 5 app. When attempting to do POST or PUT (and maybe PATCH and DELETE, although we haven't tried that yet), Angular does an OPTIONS request to verify what methods are available. No matter what we do, the OPTIONS request always response with
Access-Control-Allow-Methods →OPTIONS,POST,GET, and Angular throws an error that PUT (and curiously POST) wasn't allowed. For reference, here's a portion of the FW/1 settings from app.cfc:variables.framework = {
action = 'action',
defaultSection = 'main',
defaultItem = 'default',
reloadApplicationOnEveryRequest = true,
generateSES = true,
SESOmitIndex = true,
diEngine = "di1",
diComponent = "framework.ioc",
diLocations = [ "/model", "/controllers", "/sharedModel" ],
diConfig = { },
routes = [
{ "$RESOURCES" = "actor,movie,movieToActor" }
],
resourceRouteTemplates = [
{ method = 'get', httpMethods = [ '$GET' ] },
{ method = 'post', httpMethods = [ '$POST' ] },
{ method = 'get', httpMethods = [ '$GET' ], includeId = true },
{ method = 'put', httpMethods = [ '$PUT' ], includeId = true },
{ method = 'patch', httpMethods = [ '$PATCH' ], includeId = true },
{ method = 'delete', httpMethods = [ '$DELETE' ], includeId = true },
{ method = 'error', httpMethods = [ '$*' ] }
],
decodeRequestBody = true,
preflightOptions = true
};
[Carl Von Stetten, cfml] Doing an OPTIONS request in Postman also returns only
OPTIONS,POST,GET in the Access-Control-Allow-Methods response. But at lease we can hit POST/PUT/PATCH/DELETE directly in Postman and get back the expected results.
[Sean Corfield, cfml]
resp.setHeader( "Access-Control-Allow-Methods", "OPTIONS," & uCase( structKeyList( request._fw1.routeMethodsMatched ) ) );
[Sean Corfield, cfml] The
resourceRouteTemplates machinery generates a bunch of different routes and so each of those distinct routes will have a different set of verbs that work with them -- and therefore each route will respond differently to OPTIONS.
[Sean Corfield, cfml] To debug, I think you can dump the expanded route map...? I'm not sure what happens when you override the default routes.
[Carl Von Stetten, cfml] @kanna2591 suggested I try sticking to the FW/1 defaults, so I reverted my controller back to using the default method names (
default,show, create, update, and destroy) and removed the custom resourceRouteTemplates config setting. Here's my current app.cfc and actor.cfc: https://gist.github.com/cfvonner/1f9dfd96d43a33a178b03f98c9666fb2
[Carl Von Stetten, cfml] I'm still only seeing
OPTIONS,POST,GET returned in the Access-Control-Allow-Methods header.