Re: Paste make-config can't find the ini template file
On Thu, Aug 21, 2008 at 11:44 AM, Raoul Snyman [EMAIL PROTECTED] wrote: I did this, but when I ran paster make-config projectname config.ini, I got the following message: No paste_deploy_config.ini_tmpl found Hmph. Found out why it couldn't find it... I had somehow managed to add a space at the end of the file name... argh. -- Raoul Snyman B.Tech Information Technology (Software Engineering) E-Mail: [EMAIL PROTECTED] Web: http://www.saturnlaboratories.co.za/ Blog: http://blog.saturnlaboratories.co.za/ Mobile: 082 550 3754 Registered Linux User #333298 (http://counter.li.org) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Routes url_for with path_info parameter
You're using *var with a default value, and the magic *path_info on
top of that. All of these could interact in unexpected ways. It
would be better to make two or three specific routes for these cases,
and to use named routes for generation. That minimizes the ambiguity.
So do something like:
map.connect(home, /, controller=main, action=index)
map.connect(wiki, /WikiSystem, controller=EmbeddedTrac,
path_info=/)
map.connect(/WikiSystem/*path_info, controller=EmbeddedTrac)
h.url_for(home)
h.url_for(wiki)
Thanks, I've incorporated those changes. It didn't modify the
original behavior which causes the h.url_for(home) to be /
WikiSystem/ when called from the EmbeddedTrac controller since it's
still pre-pending the SCRIPT_NAME variable contents. No problem,
though, I'll just stick with modifying the SCRIPT_NAME hack to remove
the path part.
I ran into a few more problems with the urllib.basejoin method, so I
just used direct string manipulation which should work fine in this
case since SCRIPT_NAME shouldn't have any relative paths and should
always use forward slashes.
# fixup the SCRIPT_NAME path to go up one level
tempScriptName = environ['SCRIPT_NAME']
baseUrl = tempScriptName[0:tempScriptName.rfind('/')]
environ['SCRIPT_NAME'] = baseUrl
# render the new page
lstContent = [render(genshi, TemplateName), ]
# restore SCRIPT_NAME
environ['SCRIPT_NAME'] = tempScriptName
Routes 2 is slated to have direct delegation to WSGI apps, something like
map.wsgi(/WikiSystem, EmbeddedTrac).
I'm looking forward to Routes 2 -- it should really add a nice shine
to the whole Pylons framework.
-Eric
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: response status when form validation fails
Hello guys, Do you mind if I chime in? I agree that verify should not use 400 HTTP status code to indicate failure of verifying variable values. I don't think that even an failure to parse HTTP request body should be indicated in such a way as long as there were no failure on HTTP protocol level. Beside, forcing browser to show its standard error page for 400 error code when user simply made a mistake entering e- mail address or phone number is the straightest way to scare your users to death. HTTP is an application protocol (which resides on top of the stack), IMHO, you are mixing HTTP being an application layer protocol in OSI model with Pylons/WSGI application protocol that is unique to particular application and is partially defined by application form validation rules that are not part of HTTP protocol. Cheers, Alex --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
On Tue, 2008-08-19 at 11:43 +0200, Lawrence Oluyede wrote: I disagree. TCP is the transport protocol (which resides at the transport level of the stack). HTTP is an application protocol (which resides on top of the stack), and I'm pretty sure that the creators of HTTP intended to use 400 BAD REQUEST also for such cases. As the spec says: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. The malformed syntax they refer to is the HTTP protocol syntax (for example, malformed, missing, or improperly escaped HTTP headers, URLs, etc). The key phrase here is the request could not be understood by the server. If a form is missing a field, your server still understood (and could process) the request, it's your application that refuses the request because of its own requirements that are completely separate from the requirements of the HTTP server. Regards, Cliff --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
I'll admit at the forefront, I'm not a fan of the extreme 'restification' of the web the way the rails evangelists and followers have pushed for, or the 'restful web services' crowd. http is the transport protocol. its in the name -- Hypertext Transfer Protocol throwing a 400 on a form error is confusing to many. oauth and openid can use it, because they're creating new protocols based on mapping http stuff. oauth and openid are interpreting the 400x as something specific. if you want your app to do the same, then fine -- raise a custom redirect or set the error code yourself. it's not that hard. a large majority of people want/expect 200 for form errors. i'm all for allowing people to handle @validate better with more keywords. i've been pushing for a bunch myself -- I just don't like the idea of it being the 'new' thing as in 'backwards' compatible. i think 'forwards compatible' is a better sentiment. question though -- what if the @validate received the right params, but there was a db error or some other server error. does that become another 4xxx code in your system, or are they all lumped into the same concept. how are those instances translated into the @validate decorator? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
beaker trac
How can I submit a bug to beaker? The trac requests a password :) []'s - Walter --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
On Fri, 2008-08-22 at 18:43 -0700, Jonathan Vanasco wrote: question though -- what if the @validate received the right params, but there was a db error or some other server error. does that become another 4xxx code in your system, or are they all lumped into the same concept. how are those instances translated into the @validate decorator? Well, much of this problem is due to the same problem so much of the web has in general: all-around bad planning and poor specifications. It does seem rather inconsistent that a form shouldn't return a 40x but an internal server error returns a 50x. At the end of the day, I suppose it might be acceptable to return a 40x if you consider POST data as part of the request (at the same level as GET arguments are). So for instance it seems valid that: http://domain.com?page=bar returns a 40x and so a POST to http://domain.com with a body of page=bar should too. And once you accept that, it seems reasonable to include any invalid POST data as a 40x as well. Shrug. I reserve the right to reverse my position again after I've had another beer. Regards, Cliff --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
On 8/23/08, Alex wrote: Beside, forcing browser to show its standard error page for 400 error code when user simply made a mistake entering e- mail address or phone number is the straightest way to scare your users to death. No, on modern browsers, your form validation error page will still be displayed. I have only tested with Opera and Firefox, but even IE6 can do it if your page is larger than half a kb [1] On 8/23/08, Cliff wrote: If a form is missing a field, your server still understood (and could process) the request, it's your application that refuses the request because of its own requirements that are completely separate from the requirements of the HTTP server. When my app cannot locate a resource, it returns a 404. When my app cannot recognize the user, it returns a 401. When my app doesn't like the user, it returns a 403. When my app thinks a request is broken, it returns a 400. My app is the HTTP server. By the way, Django has a rest plugin that is hardcoded to return 400 on form validation failures [2]. Struts has a rest plugin that by default returns 400 on form validation failures [3]. Pylons already has a wonderful rest controller. I am merely suggesting to add a parameter to @validate that is defaulted to 200. Regards, Yap [1] http://support.microsoft.com/kb/q218155/ [2] http://code.google.com/p/django-rest-interface/ [3] http://struts.apache.org/2.x/docs/rest-plugin.html --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
On Aug 22, 2008, at 7:44 PM, Sok Ann Yap wrote: By the way, Django has a rest plugin that is hardcoded to return 400 on form validation failures [2]. Struts has a rest plugin that by default returns 400 on form validation failures [3]. Pylons already has a wonderful rest controller. I am merely suggesting to add a parameter to @validate that is defaulted to 200. Yea. @validate already has 4 too many options, there's no way it should have any more, in fact, it shouldn't have as many as it does. ;) It needs some serious re-working, likely as several decorators, or options that can be combined in various ways, to avoid having a single function with 10+ keyword options (ek). There was a proposal awhile back to split it up, I think that should be revisited. I see no problem with making this an option for those that want it, we just need it in a new validate setup. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
