Re: What's the best way to optimize database connections in Pyramid?
Thank you everyone for your insightful comments. I would really love to see code examples (if available) of each of these different solutions you all are describing. I feel like I'm wading into the deep end of the pool here. For the record (and for those wondering), I'm using mod_wsgi (daemon mode) for the hosting so "true" static routes aren't being handled by Pyramid, but cycling a new dbconn for every request is still not "the right way to do it" in my book. Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
What's the best way to optimize database connections in Pyramid?
I was advised a while back by someone to throw my MongoDB connection call into a pyramid.events.NewRequest subscriber. However, this has proven to be a bad idea because the NewRequest subscriber gets called even if the request is a static_route request, and since the event.request object in the NewRequest subscriber doesn't have a matched_route attribute, there's no bullet-proof way to filter those out. How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? Thanks, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Setting cookies in Pyramid for @action()s or HTTPFound redirects?
Thanks everyone! This has helped a ton. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Setting cookies in Pyramid for @action()s or HTTPFound redirects?
Currently I'm using the default cookie/session factories, but I'm looking to actually set cookies that last longer than the session so the request.session solution doesn't apply (unless I'm missing something there--I don't think it can be given a max_age). The callback method you suggested could work, but to me that's not really any simpler of a solution than creating the cookie manually and adding it to request.response_headerlist. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Setting cookies in Pyramid for @action()s or HTTPFound redirects?
I'm having the hardest time figuring out the best way to set cookies for my methods that don't return a true "Response" object (and therefore, don't have a set_cookie() method). Is there no such helper in the Pyramid stack? The closest thing I've found so far is the "Varying Attributes of Rendered Responses" section ( http://goo.gl/LwoPc ) but that doesn't really outline a helper method, and requires you to build the cookies manually and add them to the request.response_headerlist attribute. Are those of us not returning "real" Response objects stuck with building our cookie strings manually, or am I missing something here? Thanks, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Suggestions for running view code from a shell/cron?
I went down that path a little at first but got frustrated with bumping up against the fact that I'm trying to POST data to a method that I've got an ACL security policy on. I finally went the testing route because testing.setUp, testing.DummyRequest, and testing.DummySecurity policy all worked well together. Perhaps I will give it another go and be more patient this time. Thanks again, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Suggestions for running view code from a shell/cron?
Thanks for the suggestions. I actually can accomplish what I'd like to do using the pyramid.testing DummyRequest object without having to dive all the way into WebTest. As long as I'm not hearing any warnings against that here I think I'll move forward with that. Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Suggestions for running view code from a shell/cron?
This seems to me like it should be simple, so please excuse me if the answer is staring me in the face (I did some searching in the docs and elsewhere and couldn't find anything satisfactory): I'm wondering what the recommended way is to run Pyramid view code from a shell/cron. It seems like it'd be pretty simple to load the pyramid.testing module and use DummyRequest to do things like create POSTs to view methods, but since testing.* probably wasn't intended for such purposes I'm hesitant to make that leap. To be clear: I'm looking for a little more than a "from views import view_method; view_method()" approach. I'm hoping to be able to bootstrap the whole Pyramid app and actually simulate view *requests* (GET and POST) to these methods from a cron. Suggestions? Thanks, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Fixing mongo auth issues in Pyramid: Middleware or Events?
Good to know. Thanks again! Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Fixing mongo auth issues in Pyramid: Middleware or Events?
Thanks Chris, it works fine in a NewRequest event. This does bring up a minor side-question about events though: Is it better for there to be only one event call per event type, or does it matter if there are multiple? For example, in my __init__.py I'm using: config.add_subscriber(add_db_connection, NewRequest) config.add_subscriber(add_identity, NewRequest) config.add_subscriber(add_renderer_globals, BeforeRender) Is Pyramid more efficient if I combine both those NewRequest subscribers into one subscriber call, or does it matter? Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Fixing mongo auth issues in Pyramid: Middleware or Events?
I've bumped into an issue with using mongoengine and pyramid when mongoengine needs to authenticate to mongodb. My app can't connect to the database when using the paster server, although all the tests run fine. After a little googling, I came across this discussion<http://groups.google.com/group/mongoengine-users/browse_thread/thread/1aa3f9d65627c04>which describes issues with mongoengine's global connection object and suggests wrapping the connection inside middleware. What would the suggested approach be in Pyramid? Would it be recommended to go the middleware route or would it be more "pyramidic" to add this sort of thing to the "new request" event? Thanks, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 1.0b2 released
Chris, This is such exciting news! Thanks for all your hard work (and everyone else who has contributed). Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 1.0a8 released
Thanks for all the input and I suppose Marius' answer is the most straightforward solution. Perhaps I was expecting something a little more like Mike's "category" style implementation, but I can see how that could become "too much complexity for too little value." With regards to the peek_flash method: If one is using a templating system that allows python code in the template logic, this would likely be unnecessary; but for templates that only give you basic stuff like loops, tests, and prints, the peek method is needed for truth testing and multiple "non-loop" prints (i.e. printing different key/value pairs as in Marius' example). -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 1.0a8 released
Hey Chris,
With regards to the flash messaging API, is there a reason why you chose not
to provide a method which returns *any* flash message from any queue
(preferably with a msg:queue key:val)? It would sure make template code
easier if I *do* want different queues but *don't* really need them to be
displayed in a complex manner in my templates.
For example, something like this would be nice to be able to do in my jinja2
templates (without having to write my own session helpers):
{% if request.session.peek_flashes() %}
{% for flash in request.session.pop_flashes() %}
{{flash['message']}}
{% endfor %}
{% endif %}
Thanks,
Seth
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 1.0a8 released
Chris, My apologies, the 2nd issue was because I took out config.begin()/config.end() from my unittest setUp/tearDown methods because I thought they were no longer required. Adding them back causes the tests to pass. Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 1.0a8 released
Thanks Chris, I'm loving the new flash and CSRF APIs. Two thing though: 1. If you run the new proutes and it encounters an exception (i.e. an intentionally raised pyramid.exceptions.Forbidden) then it dies. Is this the intended way? 2. A bunch of my unit tests are now failing which used the config.testing_securitypolicy method (has_permission reports that "No authentication policy in use."). Was this tweaked for this release (I'm not seeing anything in the changelogs)? - Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Understanding traversal from a TurboGears perspective
Chris/Mike/Rob, *Thank you!* This discussion has help me immensely. I can see now that the config.add_handler() / @action combination is probably the best path for someone in my position to go down, and that I was probably mixing the traversal/context stuff up with my TurboGears-ish thinking. I heard on the podcast that Ben is working on a "migrating from pylons to pyramid" guide, so I suspect that will clear things up further for me. Cheers, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Understanding traversal from a TurboGears perspective
Okay, so I think I'm just having a hard time grokking the idea of a
"context" (even after beating myself to death with the documentation).
With that in mind, let me rephrase my initial question with a more
high-level question:
How is a large web application in Pyramid supposed to look?
Yes, that's a bit vague so let me clarify my thought process here:
- If I had a webapp with, say, 70+ available "routes" it seems
silly to me to specify every single view call in the config, so I
think I'd be a real fan of the config.scan() callable and the
corresponding @view_config decorator.
- TG's object dispatch (and other web frameworks I'm used to) make
the class/module hierarchy vs. url/path hierarchy pretty
straightforward, so it's more natural for me to think of a url as
traversing "controller objects" rather than having "model contexts."
- All the Pyramid example apps I've seen seem to have a single
view.py containing all the "view" methods. In a larger app setting,
wouldn't you want to split these up into separate view modules?
(forgive me, I have not gone googling for examples of large repoze.bfg
apps)
- So the issue that I'm wrestling with, of course, is how to make
the various @view_configs load the right view method from the
appropriate view module & method via a config.scan() process.
So maybe I want traversal, maybe I don't. Maybe I just need a "light-
bulb moment" about contexts. I think Pyramid's "different" way of
doing things just has me confused, coming from a background of using
frameworks that have a more "object dispatch" approach to urls/paths.
Which brings me to my new set of questions, which are:
1. What would a larger Pyramid app look like directory/module wise?
Wouldn't this look more like a default Pylons 1/TG 2 setup?
(controllers-*ahem*-views in a "views" dir, models in a "models" dir,
etc)
2. Are the Pyramid developers intentionally moving toward a less
"object dispatch" setup, and a more declarative setup where routes and
views are explicitly defined (no magic or ponies)?
3. With the movement away from controllers to a view-based setup, does
this make a Pylons 1 style "map.connect('/{controller}/{action}/
{id}')" route setup totally foreign?
4. Would a typical "large" Pyramid app then have lines and lines of
route/view definitions in the __init__.py (or other config file)?
Please forgive me if all of this seems elementary to you bfg/Pyramid
experts. I've been a web developer for years but for some reason
Pyramid is making me feel like a n00b. Again, I think I need a
revelation about contexts.
Thanks for your time,
Seth
On Dec 4, 4:23 pm, Chris McDonough wrote:
> Pyramid traversal and TurboGears object dispatch work very differently.
> In Pyramid, the graph of objects traversed isnt consulted for view
> logic. Instead, the graph is a graph of "model" objects. "Traversal"
> is the act of finding a "context". When a context is found, traversal
> has done its job. Subsequently a view is looked up based on that
> context and data in the request.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Understanding traversal from a TurboGears perspective
I've been a TurboGears user for most of my projects but have just been hired to start a new Pyramid project. Naturally, I'm interested in the traversal approach to views and routes, but am having trouble figuring out from the documentation exactly how traversal would work when spanning across multiple view classes/modules. Let's look at this typical TurboGears setup, for example (loosely adapted to Pyramid): --> The main root factory (myapp/views/root.py): <-- from myapp.views.admin.root import AdminRootView class RootView(object): def __init__(self, request): self.request = request admin = AdminRootView @view_config(renderer='string') def index(self): return 'index' --> The admin root (myapp/views/admin/root.py): <-- class AdminRootView(object): def __init__(self, request): self.request = request @view_config(renderer='string') def index(self): return 'admin index' @view_config(name='hello', renderer='string') def hello(self): return 'admin hello' Of course, in a TurboGears-style setup, this would expose views for example.com, example.com/admin/, and example.com/admin/hello. However, in Pyramid the views for the "sub-views" (/admin/*) don't seem to be able to be found. I have succeeded in making this approach work by using a "hybrid" setup (using add_route in the config and a "route_name" parameter in the view_config), but I can't help but think that there's got to be an easier way to do this and I'm just missing something. So, is this not really the intended use for traversal? The examples I found in the docs about classed-based traversal only go 1-layer deep (a Root class). I couldn't seem to land on anything solid explaining a larger app setup with views in their own subdirectory and hierarchical parent/child classes as separately traversed views. Am I making things too verbose, or am I just missing a piece of the puzzle? Thanks for your help, Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
