Hi all I can t say it enough I love FW 1 I am using version cfml #fw1

Hi all. I can't say it enough, I love FW/1. I am ...

Steve

07/30/2022, 6:56 PM

Hi all. I can't say it enough, I love FW/1. I am using version 4.3.0 and I noticed what I would call a bug, but maybe just an incorrect assumption. The application.setupResponse() is being called after the response has been output, not prior. I was hoping to add an elapsedTime field to my output within this function. It can't. I call it a bug because of the name, "setup" Response, implies just before the response is finalized, as opposed to "post" or "after" Response. Anyway, I'll figure out a way around my issue but I thought I would post my issue here.

seancorfield

07/30/2022, 7:58 PM

The docstring says:

Copy code

* override this to provide request-specific finalization
     * you do not need to call super.setupResponse()

and the

setup

prefix is kind of the common convention throughout.

seancorfield

07/30/2022, 7:59 PM

I'd have to look through the commit history to be more specific about why it was added -- I'm fairly sure it was added for a specific use case...

seancorfield

07/30/2022, 8:00 PM

https://github.com/framework-one/fw1/issues/88

Steve

07/30/2022, 8:01 PM

I just wish it was just prior to output. But I was able to adjust my code to use the after() of the controller. The only "ick" to doing it this way is duplicate code in multiple controllers or a common controller base - both I've done.

Steve

07/30/2022, 8:04 PM

Yep, #1 of the feature request I just wish it said immediately before.

websolete

07/30/2022, 10:41 PM

fwiw, your controllers can extend a base component (as well as services and daos extending their own base components if appropriate). if your controllers extend _baseController.cfc for example, you can define the after() in that base controller and only need to maintain it there. you can also define 'common' properties for DI in that base component, such as injecting fw etc. it's a good pattern for handling stuff like you describe, perhaps you hadn't considered extending base components because fw1 cfcs are special in some way? they're not.

seancorfield

07/30/2022, 10:52 PM

@websolete Steve says "or a common controller base - both I've done" so I think he's already taken that approach but just feels it is not as elegant a solution as he would like...

seancorfield

07/30/2022, 10:55 PM

@Steve For the use case you described, adding

elapsedTime

prior to view rendering, have you looked at

setupView()

Copy code

/*
     * override this to provide pre-rendering logic, e.g., to
     * populate the request context with globally required data
     * you do not need to call super.setupView()
     */
    public void function setupView( struct rc ) { }

websolete

07/30/2022, 11:44 PM

guess i didn't read his OP well, sorry

websolete

07/30/2022, 11:45 PM

or his follow up, lol.

Steve

07/31/2022, 1:04 AM

You did what I usually do. I'm glad I'm not the only one! Yes, I moved my change to the after of the controller.

websolete

07/31/2022, 1:09 AM

i've never used it so far, but the aop features in fw/1 would be another way to go. it's not clear to me if the rc scope is available to interceptors, but i imagine you could just write directly to request.context. not sure whether after() in the controller or an after interceptor is better. maybe sean can chime in on that

2 Views

Open in Slack

Previous Next