Recommended way to modify view return value

[Theron Luhn]

I’m trying to build a Pyramid equivalent to flask-apispec.  I’d like to attach a schema to a view (marshmallow is the schema library I’m using) to validate the return value of the view and marshal it into something more readily JSON serializable.

My first thought was to use a view deriver, but calling the view outputs a fully-formed Response object, so that’s a no-go.

I looked at using a view mapper, but I’m not sure I want to mess with Pyramid’s default mapper.

I tried utilizing the BeforeRender hook, but that doesn’t offer a way to replace the dictionary being passed into the renderer.  I could hack it by emptying the dictionary and inserting the new keys.

I considered building a custom renderer, but I can’t figure how I’d pass the schema into it.

I could also just use a vanilla decorator, but that covers up the view call signature.  Not the end of the world, so this is looking like the best option so far.

Any suggestions on the best way to achieve this?

— Theron

[Bert JW Regeer]

You can place a view deriver before the view is rendered by the current renderer. Unless you are returning a Response object directly from your view, you’d get the dictionary.

For example, here are the default view derivers that Pyramid includes:

https://github.com/Pylons/pyramid/blob/master/pyramid/config/views.py#L1260

You can install your new view deriver between rendererd_view and mapped_view.

This would allow you to return a dictionary from your view, and then you can do with it as you please before passing it off to the rendered_view view deriver.

Bert

[Jonathan Vanasco]

I considered building a custom renderer, but I can’t figure how I’d pass the schema into it. 

I could also just use a vanilla decorator, but that covers up the view call signature.

I do similar stuff in a variety of ways.

I almost-always augment the request object with an `add_request_method` that sets/stores/calculates the needed info for the active route.  On some routes, that data is preloaded using a decorator, on others it is looked up as needed by calculating info from the request's matched_route.

The second value to `render` methods of factory instances is `system` which should have the `request` object in it (reference the pyramid source or the cookbook for more info on that).  So the request, and custom method, is easily available within the custom renderer.

The big reason why I prefer using `add_request_method` to stash data like this is for ease in debugging.

[Theron Luhn]

Ah, I didn't realize the renderer is called by a view deriver.  All I had to do was "config.add_view_deriver(view_marshaller, under='rendered_view', over=VIEW)" and got exactly what I was looking for.

Thanks!

[Mike Orr]

I read the View Deriver documentation and delightfully found that
Pyramid has some HTTP caching options I didn't know were there: the
'http_cache' arg to 'add_view_config', and 'response.expires' and
'response.cache_control'. That will save me from having to set
Cache-Control manually in a few views that use it.

> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/adde33da-c548-47a8-a148-c4b563a77d8b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Mike Orr <slugg...@gmail.com>