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?
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/f9b07e22-8029-4b46-ad34-9ce24709642b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
