Hi,
I wonder if anyone has succeeded in caching the template output. The
main hurdle I'm facing is how to serialize the entire Response object.
I have made a tween to cache the vanilla 200 response.text, but what
about redirect, forbidden, etc, I don't have a solution.
Any pointer will be much
On 31.01.2012, at 05:48, Chris McDonough wrote:
I think it might be significantly better to just create a settings.py
module in your app and put stuff in there instead of in your config file
hm, i don't want to *maintain* the settings in python code, just have easy
access. or else i end up
fwiw: when I started using pyramid I was also reluctant to pass around
the request all the time. But it turned out to be the right (and
transparent) thing to do. In my case this is because I often need
request-specific information like the locale name basically
everywhere. Once you get used to
hi jerry,
if you run your app via paster/gunicorn/whatever proxied by apache or
nginx, it is trivial to insert varnish [1] as transparent cache
between the frontend and the server serving your pyramid app.
regards
robert
[1] https://www.varnish-cache.org/
On Tue, Jan 31, 2012 at 9:16 AM, jerry
On Tue, 2012-01-31 at 12:30 +0100, Tom Lazar wrote:
On 31.01.2012, at 05:48, Chris McDonough wrote:
I think it might be significantly better to just create a settings.py
module in your app and put stuff in there instead of in your config file
hm, i don't want to *maintain* the settings
On Jan 31, 2012, at 1:43 PM, Robert Forkel wrote:
fwiw: when I started using pyramid I was also reluctant to pass around
the request all the time. But it turned out to be the right (and
transparent) thing to do. In my case this is because I often need
request-specific information like the
On Jan 31, 2012, at 2:59 PM, Chris McDonough wrote:
If you did what that thing suggested you'd likely write a small wrapper
to run your app instead of using paster serve, so there'd be no twice.
Or at least you can arrange to do that with enough imagination.
true.
I personally find that
Switched to bottom-posting to make it easier to discuss this.
On Jan 27, 6:50 pm, Jemes Hsu jemes...@gmail.com wrote:
Pyramid is carrying a lot of old baggage. Reading about Pyramid, you are
reading the history about repoze, ZOPE and Pylons and about Pylons
projects. One needs to understand
On 31 January 2012 13:43, Robert Forkel xrotw...@googlemail.com wrote:
fwiw: when I started using pyramid I was also reluctant to pass around
the request all the time. But it turned out to be the right (and
transparent) thing to do. In my case this is because I often need
request-specific
On Tue, Jan 31, 2012 at 3:30 AM, Tom Lazar t...@pyfidelity.com wrote:
i really would like to have a clean, convenient and supported way to access
global settings. i guess, the answer is that pyramid currently doesn't have
this on offer.
generically exposing the settings that were used to
Am Montag, den 30.01.2012, 10:27 -0800 schrieb Jonathan Vanasco:
could you share the code that raised the exception , or an
approximation of it ?
All approximations I tried do not reproduce the exception. Seems to
depend on the context or circumstences. Well, the code connects to
almost
On Jan 31, 2012, at 3:27 PM, Malthe Borch wrote:
Another option – in terms of the right thing – is to derive an
object that carries just to things you need from the request, e.g.
locale and logged in user, so that you don't pass around an HTTP
request everywhere (and hence need to stub it out
But maybe now there's a new generation of users who don't have a
either Pylons or a BFG background, who find all the history and
non-Pyramid alternatives distracting. If so... again, I don't think we
want to rip the manual and website apart to address it. But maybe the
documentation intro
Thanks Robert.
However, the cache needs to, at minimum, differentiate login users
from non-login users to serve different content, and only a Pyramid
app aware caching engine can do that.
Jerry
On Jan 31, 9:44 pm, Robert Forkel xrotw...@googlemail.com wrote:
hi jerry,
if you run your app via
I wonder if this solves your issue with Varnish, or if it is too coarse:
https://www.varnish-cache.org/docs/trunk/tutorial/cookies.html
It would seem as a minimum you could identify logged-in-users from
non-logged-in-users by a the presence of a specific auth-cookie. This would
certainly
Next website will be Pyramid branded and be available by next pycon :)
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/Q1xkgMbuHt4J.
To post to this
Thanks Simon. Varnish is definitely worth exploring.
I'm also very interested in your second approach, how can you tell if
the user has JS enabled by looking at her request?
Jerry
On Jan 31, 11:45 pm, Simon Yarde simonya...@me.com wrote:
I wonder if this solves your issue with Varnish, or if
I come from Pylons, where we had the g globals object. I miss it
dearly.
The Pyramid/Repoze group seems very much into the idea of passing a
request around all the time. I don't like that, mostly from the 'mass
appeal route' , in that its something that just about every other
framework has, and
On Tue, 2012-01-31 at 09:33 -0800, Jonathan Vanasco wrote:
I come from Pylons, where we had the g globals object. I miss it
dearly.
The Pyramid/Repoze group seems very much into the idea of passing a
request around all the time. I don't like that, mostly from the 'mass
appeal route' , in
I wouldn't try to tell from a cookie, I would just put something like this in
the template::
a id=my_account href=/users/my_accountMy Account/a
then have a script grab a json response containing minimal user info and modify
the link::
a id=my_account href=/users/1234Jane
On Tue, Jan 31, 2012 at 9:33 AM, Jonathan Vanasco jonat...@findmeon.com wrote:
I come from Pylons, where we had the g globals object. I miss it
dearly.
The Pyramid/Repoze group seems very much into the idea of passing a
request around all the time. I don't like that, mostly from the 'mass
Hello everyone,
From the object-oriented point of view, a Pyramid View (instance of a
callable class) depends on the context and the request. Pyramid,
correctly injects those dependencies into the view, during a view's
class instantiation (while processing a Request).
Assuming that a view
True, when i started learning pyramid, i tried to search on google and it
returned results about 'egyptian pyramids'!
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To
On Tue, 2012-01-31 at 11:22 +0530, chandrakant kumar wrote:
True, when i started learning pyramid, i tried to search on google and
it returned results about 'egyptian pyramids'!
I'd hope so!
- C
--
You received this message because you are subscribed to the Google
Groups
On Tue, 2012-01-31 at 15:09 -0800, papagr wrote:
Hello everyone,
From the object-oriented point of view, a Pyramid View (instance of a
callable class) depends on the context and the request. Pyramid,
correctly injects those dependencies into the view, during a view's
class instantiation
On Tue, 2012-01-31 at 15:06 -0800, Mike Orr wrote:
On Tue, Jan 31, 2012 at 9:33 AM, Jonathan Vanasco jonat...@findmeon.com
wrote:
I come from Pylons, where we had the g globals object. I miss it
dearly.
The Pyramid/Repoze group seems very much into the idea of passing a
request
my .02¢ is this:
App Developers like features like 'Globals'. It's something that is
familiar-from, and present-in many other frameworks.
Granted, pyramid is a low-level framework - and one that a more 'webmonkey'
friendly framework might be built upon itself. But those frameworks are
On Tue, 2012-01-31 at 20:16 -0800, Jonathan Vanasco wrote:
my .02¢ is this:
App Developers like features like 'Globals'. It's something that is
familiar-from, and present-in many other frameworks.
Granted, pyramid is a low-level framework - and one that a more
'webmonkey' friendly
28 matches
Mail list logo
