#pyramid

hi :)

Does anyone know the right way to get IBeforeRender signals to occur when calling `render_to_response`?

or the proper way to do so :) Trying to unit test template rendering

monokrome: they should just work... make sure you are passing request=request possibly

raydeo: Hmm... I'm passing `request=self.request`, but no luck

make sure they are subscribed

if it's a unit test maybe you didn't scan them

Also, sorry about not looking into Accept header stuffs... Seemingly got distracted and lost the channel :'(

fortunately for you it's still in the same state it was ;-)

I imported the module manually, and they are subscribed via decorators. I think that should have registered them?

Ha, well unfortunately it's still a bug :'( !

you must config.scan the module

config.scan('pyramid.subscribers') in setUp didn't seem to work either

At least I know I'm on the right track, though! Thank you :)

no

you need to scan *your* subscribers

Sorry, I meant 'aviation.subscribers' - freudian slip :)

aviation is my project :)

ok well if they are decorators that should help

maybe you need to config.commit() if you aren't making a wsgi app

Yep. Looks like it gets called now, but the template gets rendered before it gets called? O_o

huh

I probably broke somethign :D

raydeo: aaah... It looks like this specific thing is using config.action, but that maybe doesn't work in unit tests? O_o

it works fine in unit tests

I called into config.action manually and did a config.conmmit() afterward in the test

feel free to paste a chunk of your code... it's a little difficult to debug the abstract

hehe sorry :)

actions work fine, but they have a few different modes of operation

raydeo: https://gist.github.com/monokrome/707d48a391c3a...

Hope that helps?

an order of infinity seems a little aggressive ;-)

haha yeah :)

That's like my "I don't mind as long as it happens" :D

so pyramid.testing.setUp() creates the configurator in autocommit mode

meaning every action executes immediately instead of waiting for a config.commit()

it also means order is irrelevant

so if you care about such things then pass autocommit=False to setUp()

I don't :)

so what's the issue here?

I don't see the actual test code so I can only assume you're saying that a BeforeRender is executed somewhere in the ether before render_to_response

I guess this one doesn't use IBeforeRender any more, let me add more relevant code

raydeo: I added the shortcuts part, and both functions execute - but `serialize` isn't in the template filters

ok so this isn't a BeforeRender question anymore I take it

raydeo: Yeah, sorry - I just mentioned that. Sorry!

gotcha

Is the without filter there? or they're both missing

but I guess it's weird that the test executes that get_jinja_action, if I print jinja2.filters then it is as expected, but jinja raises an error about the filter not existing

Maybe I need to do something to bind the dummyrequest to self.config? I don't think they know about eachothyer.

it's not necessary generally... the dummyrequest will find the config between setUp and tearDown

hmm ok

"as long as no template was loaded it's safe"

feels like a clue to me

Same, but this is the first template in any of our unit testing

have you tried using pyramid_jinja2's support for filters?

I'll look into that. I thought that was what I was doing :)

for example config.add_setting({'jinja2.filters': 'serialize=json.dumps'})

note that you need to set the setting prior to including pyramid_jinja2 because of the autocommit mode

I'm surprised your code doesn't work though, it seems ok

just good to try alternatives to narrow it down

raydeo: Aaaaaah! It worked!!! :D

Thank you!

that surprises me considering pyramid_jinja2 is also just changing the filters dict

I bet it's an ordering issue? Maybe scanning subscribers broke timing or something

there's no threads here, so timing is out, but possibly an ordering thing

Nope, I removed config.scan so that didn't do it

I meant ordering :)

Maybe config.action is causing it somehow?

Nope... Same issue if I manually call it. This is weird

are you *sure* that the action is invoked?

yep

I printed the filters dict from the last line in the inner function and got output

yeah ... hmm

Thanks for your help. I probably would have given up on that one :o

really weird

sure, if you had a reprodoucible little thing I could run I'd probably figure out wtf is going on but without it I'll just find a broom and a rug

I can try to make one after I send this PR!!! :)

Would be good to know what happened even if it's solved indirectly?

right

man python is weird https://paste.ofcode.org/7k8fu2GpPPRMYZvuy9wKHc