gi (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
&q
ched_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
p
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.
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 coul
esponse 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
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 u
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
--
Yo
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 s
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...@googlegroup
riber(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 yo
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@googlegro
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 u
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
ashes() %}
{{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, se
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
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
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
up 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 s
ased 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 p
19 matches
Mail list logo
