Re: beaker configuration
I had already started using beaker 1.6 and it seem to work fine as long as I included a key_length key for each region definition: cache.short_term.expire = 60 cache.short_term.key_length = 256 -- 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/-/C066j-BJmhwJ. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: cleaning up after a request, always?
How come you guys aren't using ZopeTransactionExtension for this , i.e. http://docs.pylonsproject.org/projects/pyramid/en/1.2-branch/tutorials/wiki2/basiclayout.html#content-models-with-models-py? My understanding is that session scope should be entirely handled in that case. I'm using a non-global session setup, similar to what's described here: http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/sqla.html#using-a-non-global-session, and the code above seemed like the simplest way to ensure the session gets closed without adding another dependency. At a glance, I don't like the idea of having to `import transaction`. That said, I haven't really looked at the ZopeTransactionExtension. What is the advantage to doing `transaction.commit|abort` vs. `session.commit|rollback`? -- 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/-/OoGyNum7zbkJ. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: cleaning up after a request, always?
On Mon, 2011-11-21 at 07:51 -0800, Wyatt Baldwin wrote: How come you guys aren't using ZopeTransactionExtension for this , i.e. http://docs.pylonsproject.org/projects/pyramid/en/1.2-branch/tutorials/wiki2/basiclayout.html#content-models-with-models-py ? My understanding is that session scope should be entirely handled in that case. I'm using a non-global session setup, similar to what's described here: http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/sqla.html#using-a-non-global-session, and the code above seemed like the simplest way to ensure the session gets closed without adding another dependency. At a glance, I don't like the idea of having to `import transaction`. That said, I haven't really looked at the ZopeTransactionExtension. What is the advantage to doing `transaction.commit|abort` vs. `session.commit|rollback`? http://docs.pylonsproject.org/projects/pyramid/en/1.2-branch/narr/introduction.html#transaction-management - C -- 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/-/OoGyNum7zbkJ. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: cleaning up after a request, always?
On Mon, Nov 21, 2011 at 7:55 AM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-11-21 at 07:51 -0800, Wyatt Baldwin wrote: How come you guys aren't using ZopeTransactionExtension for this , i.e. http://docs.pylonsproject.org/projects/pyramid/en/1.2-branch/tutorials/wiki2/basiclayout.html#content-models-with-models-py? My understanding is that session scope should be entirely handled in that case. http://docs.pylonsproject.org/projects/pyramid/en/1.2-branch/narr/introduction.html#transaction-management To be honest, the only reason I'm not using it is because when I started my framework with repoze.bfg 2 years ago, the docs on zope transaction management were still pretty minimal and I didn't feel like I understood what it was doing properly. I'll read the above and quite possibly change my mind! I do like knowing that I'm using zero magic globals or thread locals anywhere though, just makes it easier to track down and goof ups in the threading and session management. I have all my db calls wrapped up in one abstract model class that gets attached to request, and SA doesn't get used any other way. thanks for the tip ( and the every improving but already amazing docs! ) I've said it before a lot, but IMHO Pyramid has the best technical docs of any project I've used ever. kudos again. Iain -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Form field processing
fwiw, we use formencode heavily. The facilities for encoding and decoding
nested form variable names are really really well designed.
iain
On Mon, Nov 14, 2011 at 11:47 PM, Chris McDonough chr...@plope.com wrote:
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 for Python that offer similar features
(formencode, deform, toscawidgets, formish, and so forth).
There is also http://pypi.python.org/pypi/repoze.monty/0.1 which handles
stuff like this.
If none of these are sufficent, patches, as always, are accepted.
- C
On Nov 15, 12:04 am, Gael Pasgrimaud g...@gawel.org wrote:
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():
if k.startswith('profile-'):
profile[k[len('profile-'):]] = request.POST.get(k)
name = profile.get('name', 'Bob')
Or use a form library. FormAlchemy allow to use a prefix and I guess
that deform and other libraries have way to do that too.
If you need this kind of structure that mean that you want to build
complex forms. Build html forms and validation stuff by hand is not
really fun and not very efficient.
My 2c.
On Mon, Nov 14, 2011 at 12: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, 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')
Sorry, rather:
request.POST.getall('foo')
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 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:
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 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'
name='profile[password]'
so when this form is submitted, it would be cool
if I
can just do
like: request.POST['profile'] which gives me a
dict of
names and
values specific to that model/table whatever
so if I do request.POST['profile'] = {'username':
value
entered by
user, 'password': value entered by user}
is this feature already there? or can it be
achieved in
any other way?
is it related to webob or pyramid?
I am ready to work on this to make it available in
pyramid, so please
give me pointers to work on this.
--
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 unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/pylons-discuss?hl=en.
--
You
Re: cleaning up after a request, always?
The biggest argument I have for transaction management is a product of how views interact with the Pyramid rendering system. Templates are rendered *after* you have returned from your view unless you explicitly call render() or render_to_response(). If you call commit() in your view, that data is persisted whether or not the template renders. This is typically a bad thing. There are other ways to do transaction management manually of course, like in the requests's reponse callback you can do the commit, and in the request's finished callback you can do the rollback, fully wrapping the request. However, the ZTE (ZopeTransactionExtension) does all of this for you and it's a great way to tie multiple operations into a single commit operation, outside of simply database commits. For example repoze.filesafe or pyramid_mailer which can delay file creation and email sending until we are sure the request is completed successfully. -- Michael -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: cleaning up after a request, always?
On Nov 21, 2011, at 2:09 PM, Michael Merickel wrote: The biggest argument I have for transaction management is a product of how views interact with the Pyramid rendering system. Templates are rendered *after* you have returned from your view unless you explicitly call render() or render_to_response(). If you call commit() in your view, that data is persisted whether or not the template renders. This is typically a bad thing. This is a common thing I talk to folks about and I'm on the other side of that, at least in terms of the content of the template being ready to be sent to the client.SQLAlchemy's default behavior is to expire all data after a commit - the transaction is gone, so if you access your objects subsequent to that, a new transaction is started and the data is reloaded. ORM objects in SQLAlchemy (as well as in most other ORMs) are *proxy* objects - they load new data from the database as needed. if there's no transaction, a new one is begun. Assuming your template does anything regarding model objects, it will hit their attributes and begin a *new* transaction and all the data will load all over again. You can disable SQLAlchemy's expire-on-commit behavior, but even then if your template hits mymodel.some_new_attribute that wasn't already loaded, you're still starting up a new transaction. So it's very likely that rendering the template after the commit in a traditional proxy-model approach will mean you have *two* transactions. In the traditional model of the template accessing objects that are essentially lazy proxies, the rendering step itself IMHO should be within the single transaction. Then you commit, then if successful you actually return the content. Of course if you're doing some other kind of template model, such as converting the full span of data into a JSON type of structure first, then the template renders from a fixed structure (either server side or client side), then you've changed the boundaries, thats fine. But I still find great utility in the model of templates rendering directly from model proxy objects, and for that I prefer only a single transaction be used. -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Serving Images Dynamically
I'm trying to figure out the best way to serve images dynamically in Pylons. Right now, I'm uploading images to a folder in /public. However, I want to be able to provide permissions to images as well as store them in a different manner (e.g. in a database). What would be the best way to handle this? -Vincent -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Serving Images Dynamically
On Mon, Nov 21, 2011 at 2:48 PM, Vincent Catalano
vinc...@vincentcatalano.com wrote:
I'm trying to figure out the best way to serve images dynamically in
Pylons. Right now, I'm uploading images to a folder in /public. However, I
want to be able to provide permissions to images as well as store them in a
different manner (e.g. in a database). What would be the best way to handle
this?
You could do something like:
@view_config(permission='authed', route_name='view_image')
def view_image(self):
new_file = open('filename.svg')
response = Response(content_type='image/svg+xml')
response.app_iter = new_file
return response
--
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 unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: Serving Images Dynamically
John, he's using Pylons. -- Michael -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Serving Images Dynamically
This also work with Pylons. Except for the decorator. You can replace it with a custom one or by repoze.what But the best way is to use a X-Sendfile (or similar) header: http://www.yiiframework.com/wiki/129/x-sendfile-serve-large-static-files-efficiently-from-web-applications/ (It's about PHP but HTTP headers are the same in all languages) On Mon, Nov 21, 2011 at 10:19 PM, Michael Merickel mmeri...@gmail.com wrote: John, he's using Pylons. -- Michael -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Serving Images Dynamically
Thanks! On Mon, Nov 21, 2011 at 2:28 PM, Gael Pasgrimaud g...@gawel.org wrote: This also work with Pylons. Except for the decorator. You can replace it with a custom one or by repoze.what But the best way is to use a X-Sendfile (or similar) header: http://www.yiiframework.com/wiki/129/x-sendfile-serve-large-static-files-efficiently-from-web-applications/ (It's about PHP but HTTP headers are the same in all languages) On Mon, Nov 21, 2011 at 10:19 PM, Michael Merickel mmeri...@gmail.com wrote: John, he's using Pylons. -- Michael -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- Vincent Catalano Software Engineer and Web Ninja, (520).603.8944 -- 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 unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
