response caching (and a possible docs error)

[Jonathan Vanasco]

This is an extension of something I brought up about a year ago.  I'm unhappy with my current approach and trying to figure out a better way to implement this.  I'm not sure it might be possible though.

When it comes to "public urls", our application caches responses from views as a tuple of `(generated_string, page_metadata)`.  Data isn't cached into Varnish (or similar) because there is server-side processing done via Pyramid on the `page_metadata` via tweens and middleware.

The current implementation is less than ideal -- in order to coordinate all the bits of data where we need them, we use a generator function:

    class ClassViews(handler):

        @view_config(route_name="foo"):

        def foo(self):

              self._foo(kwags_1)

        @cached_response(kwargs_2)

        def _foo(self, kwargs_1):

             return Response()

This approach gives 2 possible hooks for kwargs that can be used to determine the right cache keys.  One of the drawbacks to this is that we lock in the response renderer.  This is fine for now and may never change, but I feel this is creating technical debt if we shift.

I've been trying to consolidate this into a streamlined way to invoke this which can still use the response adapters.

This is where the possible docs error is:

I was looking at the `decorator` arg to view_config (http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#non-predicate-arguments) and it says:

@view_config(..., decorator=(decorator2, decorator1))

def myview(request):

 ...

Is similar to doing:

@view_config(...)

@decorator2

@decorator1

def myview(request):

 ...

But after noticing something in the request lifecycle diagram, and confirming in a quick test, this isn't the case:  The `view_config(decorator=) kwarg approach will wrap AROUND the response adapter, however the @decorator syntax will wrap WITHIN the adapter.

For our current needs, we seem to need attributes from both sections:

1. The `view_config(decorator=) kwarg offers an adapted response.  This is great, because it would allow us to use the `renderer=` kwarg instead of using a call to `render_to_response`. unfortunately, we don't have the information about the route/renderer handy.

2. The `@decorator(`  offers the chance to register logic that can be used to determine the cache key and strategy via kwargs.  Some routes have 10 `@view_configs` -- using the same logic to drive different templates/routes.  

The only thing I can think of so far, is a `@decorator` syntax to register configuration information for a view, and then doing cache/generation options via the `view_config(decorator=)` syntax.

Has anyone else been working on stuff like this and have ideas to share?