Many thanks again. It felt quite natural to handle/raise/re-raise exceptions in
the exception view since this has become the exception handler so-to-speak.
However, looking at the problem again, the code is much easier to follow as a
result of placing all of the application's
Hi All
Does anyone have any information on progress for Pyramid Debug Toolbar issue
#44?
The issue causes the exception below when URI's contain accented characters (in
my case 'ü'). Pyramid behaves normally without error when debug toolbar is
turned off.
A temporary patch/workaround would
Am 14.11.2011 11:02, schrieb Simon Yarde:
A temporary patch/workaround would be really useful, other than turn off
debugging :)
Here is a patch for this issue, let us know how it works:
https://github.com/Pylons/pyramid_debugtoolbar/pull/43
-- Christoph
--
You received this message
Sure, I'll whip something up.
Thanks.
.oO V Oo.
On 11/14/2011 06:01 AM, Chris McDonough wrote:
I hate to ask, but would it be possible to concoct a short Python script
that creates a SQLA DBSession (with the ZopeTransactionExtension
enabled) that issues transaction.commit/savepoint/abort
Thanks for your reply :)
This may be a big ask... but could you briefly outline the steps I would need
to take to download pyramid debug toolbar from github and apply the patch; and
following this how I would update it for future tagged releases?
I'm very happy to read any documentation.
Here:
https://gist.github.com/1363860
This simple test case works just fine, meaning the problem is somewhere
in my application. As you can see from the code, I tried both a
standalone test and through Pyramid WSGI chain checking if pyramid_tm
middleware possibly borks something somewhere,
Eh... please excuse my haste, having ton of work this morning and my
brain is already melting... :)
It fails after all, exactly the same way as in my app:
https://gist.github.com/1363906
Output:
Outer transaction...
First pass...
INSERTED
Second pass...
UPDATED
tm.name:
Traceback
Do easy_install -U pyramid_debugtoolbar, latest version is 0.9.5 and
templates are now mako based.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To view this discussion on the web visit
Am 14.11.2011 12:34, schrieb Simon Yarde:
This may be a big ask... but could you briefly outline the steps I
would need to take to download pyramid debug toolbar from github and
apply the patch; and following this how I would update it for future
tagged releases?
Well, the easiest way is to
Is there anyway to check if the user have the required permissions
when I only know the route_name?
def main(global_config, **settings):
[snip]
config.add_route('administrations', '/administrations')
class Administration(object):
def __init__(self, request):
Hi,
Are you coming from php ? :)
WebOb does not handle arrays/hashes and I don't think that this is in
the current roadmap.
On Mon, Nov 14, 2011 at 7:52 AM, uday gotou...@gmail.com wrote:
Hi all,
I think it is more helpful if we can make form fields processing more
convenient which can
Hi all,
I think it is more helpful if we can make form fields processing more
convenient which can reduce verbosity in views.
for example assume profile model/table has fields username and
password
in my form i write likeinput type='text'
name='profile[username']input type='password'
On Mon, 2011-11-14 at 09:28 -0800, Mengu wrote:
actually, pylons had this. it was request.params.getall('param') but
pyramid does not support this.
It does, actually. It's a WebOb feature (both Pyramid and Pylons use
WebOb).
- C
On Nov 14, 6:12 pm, Gael Pasgrimaud g...@gawel.org wrote:
Are your sure ? WebOb still have this feature:
https://github.com/Pylons/webob/blob/master/webob/multidict.py#L96
But that's two different behaviors. .getall() return a list of all
values for the same field (two input / with the same name)
On Mon, Nov 14, 2011 at 6:28 PM, Mengu
The key[subkey] syntax is not supported in WebOb (I think).
On Mon, Nov 14, 2011 at 11:41 AM, Chris McDonough chr...@plope.com wrote:
On Mon, 2011-11-14 at 09:28 -0800, Mengu wrote:
actually, pylons had this. it was request.params.getall('param') but
pyramid does not support this.
It
You can use pyramid.security.has_permission() to check access to a
particular permission. view_execution_permitted is traversal-only.
For has_permission() you just need to be sure to pass in the context that
contains the correct ACLs for that view.
On Mon, Nov 14, 2011 at 12:18 PM, Mark Erbaugh
On Mon, 2011-11-14 at 12:21 -0600, Michael Merickel wrote:
The key[subkey] syntax is not supported in WebOb (I think).
Yeah, sorry. I meant that when you do this in a form:
input type=text name=foo/input
input type=text name=foo/input
You can do in a view:
request.getall('foo')
On Mon,
On Mon, 2011-11-14 at 13:27 -0500, Chris McDonough wrote:
On Mon, 2011-11-14 at 12:21 -0600, Michael Merickel wrote:
The key[subkey] syntax is not supported in WebOb (I think).
Yeah, sorry. I meant that when you do this in a form:
input type=text name=foo/input
input type=text
uday, I think you'll want to just prefix your values, then you can iterate
over the POST and turn it into a dictionary:
input name=profile-name/
input name=profile-email/
profile = {}
for k in request.POST.keys():
if k.startswith('profile-'):
profile[k[len('profile-'):]] =
I'm not sure it's appropriate to check permissions based on route
names. I haven't done this yet in Pyramid, but in Pylons I used
external knowledge to decide if the user should see certain links, and
passed a boolean to the template: true = show the links, false =
don't show them. If the user
On Mon, Nov 14, 2011 at 7:37 PM, Michael Merickel mmeri...@gmail.com wrote:
uday, I think you'll want to just prefix your values, then you can iterate
over the POST and turn it into a dictionary:
input name=profile-name/
input name=profile-email/
profile = {}
for k in request.POST.keys():
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after failed session.
Is there any benefit of the Transaction in Pyramid if all I'm using is
it for is SQLAlchemy (and don't need transaction abstraction)? In fact
I'm
On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote:
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after failed session.
Is there any benefit of the Transaction in Pyramid if all I'm using is
it for is SQLAlchemy (and
On Mon, 2011-11-14 at 14:38 -0500, Chris McDonough wrote:
On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote:
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after failed session.
Is there any benefit of the
Whenever I call a method decorated with cache_region it is still executing
the method every time it is called (as I see with a print statement while
in development).
I have my beaker config in the INI file:
cache.regions = default_term, second, short_term, long_term
cache.type = memory
On Mon, 2011-11-14 at 21:14 +0100, Vlad K. wrote:
Because each savepoint must be met by one commit or one rollback. If I
use session.flush(), the second call would start savepoint 2, but would
not release savepoint 1 (nor roll it back). While that may work fine
for this case, I am not sure
On Nov 14, 2011, at 2:44 PM, Chris McDonough wrote:
Out of curiosity, why are you committing in the middle of view logic?
It's none of my business really, but session.flush() would seem to get
you what you want and would work fully within the one-request-one-commit
policy.
hear, hear !
When using Transaction the rollback is emitted implicitly either by
Transaction or by zope.sqlalchemy, and manually calling
savepoint.rollback() after a failure results with
InvalidSavepointRollbackError. At least that was the case when I tried
that, please see earlier posts in this topic.
This is probably because the arguments to the method change every time the
method is called. i.e. self is a different instance of your class every
time.
On Mon, Nov 14, 2011 at 1:49 PM, Jason ja...@deadtreepages.com wrote:
Whenever I call a method decorated with cache_region it is still
You're absolutely right. Caching instance methods with the cache_region
decorator is only supported in Beaker 1.6 and higher. I'm using 1.5.4
(thanks for debug toolbar letting me easily see the versions).
-- Jason
--
You received this message because you are subscribed to the Google Groups
Don't upgrade to 1.6 quite yet. pyramid_beaker doesn't support it until its
next release which I hope will be very soon.
On Mon, Nov 14, 2011 at 3:21 PM, Jason ja...@deadtreepages.com wrote:
You're absolutely right. Caching instance methods with the cache_region
decorator is only supported in
On Tue, 2011-11-15 at 02:57 +0100, Vlad K. wrote:
This has turned into a much bigger issue than I originally thought it would.
As suggested by Chris here and Michael on the SQLAlchemy list where I
asked first about refreshing sessions, this problem is solvable if you
reload any model you
On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote:
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after failed session.
By the way, are you sure about this? I've heard that when you commit or
abort a raw SQLA session,
On Nov 14, 2011, at 10:14 PM, Chris McDonough wrote:
On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote:
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after failed session.
By the way, are you sure about this? I've
On Mon, 2011-11-14 at 22:40 -0500, Michael Bayer wrote:
On Nov 14, 2011, at 10:14 PM, Chris McDonough wrote:
On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote:
For worse I'd say because using SQLAlchemy directly works just fine and
as expected, without the need to reload the data after
Thanks for the suggestion. Is it really that hard to implement this?
I work with rails in my day job, it has this feature which reduces lot
of verbose code in controllers
and also it makes form handling so easy.
On Nov 15, 12:04 am, Gael Pasgrimaud g...@gawel.org wrote:
On Mon, Nov 14, 2011 at
This is different from what I am asking.
On Nov 14, 11:29 pm, Chris McDonough chr...@plope.com wrote:
On Mon, 2011-11-14 at 13:27 -0500, Chris McDonough wrote:
On Mon, 2011-11-14 at 12:21 -0600, Michael Merickel wrote:
The key[subkey] syntax is not supported in WebOb (I think).
Yeah,
Have you taken a look at Peppercorn (http://plope.com/peppercorn)? It
offers a way to deserialize forms that is closer to what you're asking,
though not an exact match.
But I think this might be a case where there's no direct translation from
other languages/frameworks into Python/Pyramid. To see
On Mon, 2011-11-14 at 23:18 -0800, uday wrote:
Thanks for the suggestion. Is it really that hard to implement this?
I work with rails in my day job, it has this feature which reduces lot
of verbose code in controllers
and also it makes form handling so easy.
There are a lot of form libraries
39 matches
Mail list logo
