Purge/empty request.get?
Hi, Is there a simple way to remove the request.get variables? I have a page that uses .GET to store a load of form elements data as the page can be resent to the controller at any time [onchange event on a select] but is not actually stored at this time, and these get vars are used to repopulate the page. However I'd very much like for them to not be in the url after the page is loaded. The Get vars are all put into a c variable when the controller is recalled - it would be cool to purge / empty .GET so that when the render command returns the URL is nice and tidy again. Any ideas much appreciated. Jules --~--~-~--~~~---~--~~ 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: Why does a route with unmatched conditions give 500 and not 404?
On Wed, Nov 12, 2008 at 9:44 PM, Mike Orr [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 2:00 AM, mario ruggier [EMAIL PROTECTED] wrote:
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
It should be 404 and it usually is. There must be a bug in how it
processes the particular argument combination. What happens if you
comment out the second route and remove the condition in the first?
If I do that then both GET and PUT (and all other verbs) requests are
routed to GET_action.
If (from the initial routes above) I instead comment out the PUT and
OTHER routes altogether (leaving the GET with its condition) and then
I request a PUT on same URI, the server responds with a 500:
NotImplementedError: Action u'action' is not implemented.
m.
--~--~-~--~~~---~--~~
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: Why does a route with unmatched conditions give 500 and not 404?
On Thu, Nov 13, 2008 at 2:58 AM, mario ruggier [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 9:44 PM, Mike Orr [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 2:00 AM, mario ruggier [EMAIL PROTECTED] wrote:
I would like to support specific http verbs on a given URI. For example, to
support GET and PUT for the URI /controller/action/id I have defined these
2 dedicated routes:
map.connect('/controller/action/:id', controller='controller',
action='GET_action', conditions=dict(method=['GET']))
map.connect('/controller/action/:id', controller='controller',
action='PUT_action', conditions=dict(method=['PUT']))
Issuing a GET or PUT for this (same) URI will cause the correct action to
be executed... however, if I issue a request with a different method, such
as a POST, the response is a 500 Internal Server Error. I would have
expected a 404 Not Found, as is normally returned for no matching route.
A simple workaround (amongst other more elaborate -- and imho more
convoluted -- local dispatching mechanisms) is to follow up the above
routes with a catchall for the any other verbs:
map.connect('/controller/action/:id', controller='controller',
action='OTHER_action')
that would then be supplied as a method on controller simply to return 404:
def OTHER_action(self, id):
abort(404)
So, why the 500 and not the 404 in the first place?
Any other suggestions of how best to handle such situations?
It should be 404 and it usually is. There must be a bug in how it
processes the particular argument combination. What happens if you
comment out the second route and remove the condition in the first?
If I do that then both GET and PUT (and all other verbs) requests are
routed to GET_action.
If (from the initial routes above) I instead comment out the PUT and
OTHER routes altogether (leaving the GET with its condition) and then
I request a PUT on same URI, the server responds with a 500:
NotImplementedError: Action u'action' is not implemented.
Is that what the action name should be, or does it always say 'action'?
I tried this and got 500 with development.ini and 404 with
production.ini. My error was NotImplementedError: Action
u'GET_action' is not implemented. If that's what's happening, it's
the correct behavior. In development mode it produces an interactive
traceback because it assumes you forgot to implement the method or the
route is wrong or something, and interactive tracebacks have status
500. When you set debug=false, it changes the error to 404 to avoid
giving any private information to potential attackers.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
pylons templates
Hi all, I have deployed my application on a debian lenny server, apache 2.2.3, mod_wsgi 2.3. I changed some templates (page layout, pretty colors for users ...), but the changes are not visible - the page layout is still the same, no change in color or anything else (after apache rester and also after whole machine reboot) ... however when I start paster server ... everything works as it should be :( If I remove some mako templates, then I get 500 error and a log message (apache's error.log) saying that couldn't find file blabla.mako. Apache mods I am running: core mod_log_config mod_logio prefork http_core mod_so mod_alias mod_auth_basic mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dir mod_env mod_mime mod_python mod_negotiation mod_perl mod_php5 mod_setenvif mod_status mod_wsgi There is no caching server in the way and no wrong firewall rule. Any advice? Thanks in advance. Karol --~--~-~--~~~---~--~~ 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: Why does a route with unmatched conditions give 500 and not 404?
On Thu, 13 Nov 2008 07:22:16 -0800, Mike Orr [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 2:58 AM, mario ruggier [EMAIL PROTECTED] wrote: NotImplementedError: Action u'action' is not implemented. Is that what the action name should be, or does it always say 'action'? It will show the real name of the action (the prematched action value, in the incoming URL... I tried this and got 500 with development.ini and 404 with production.ini. My error was NotImplementedError: Action u'GET_action' is not implemented. If that's what's happening, it's the correct behavior. In development mode it produces an interactive traceback because it assumes you forgot to implement the method or the route is wrong or something, and interactive tracebacks have status 500. When you set debug=false, it changes the error to 404 to avoid giving any private information to potential attackers. Ah, it is the debug mode, it does give 404 when debug is set to False... sorry about not realizing that it would behave differently because of this. Thanks a lot for pointing this out! m. --~--~-~--~~~---~--~~ 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: Pylons/ Tesla bind problem
Try putting the data manip stuff inside of: yourapp/model/__init__.py in the: def init_model(engine): Put data initialization in here... On Nov 13, 3:16 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks for the response! I'll root around and if I find the culprit, I'll post my findings back here. On Nov 12, 5:00 pm, Mike Orr [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 2:41 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi everyone! I'm diving into Pylons and Tesla for the first time and I'm running into an issue while querying on any table. Example: code % paster shell model.Location.query.all() UnboundExecutionError: Could not locate a bind configured on mapper Mapper|Location|Location, SQL expression or this Session /code I can use this Elixir model just fine outside of Pylons/ Tesla. I'm guessing I'm not wiring something correctly. Any help would be _greatly_ appreciated. I can tell you what's happening in general, but not specifically what's wrong in the Tesla configuration. Whatever is performing the SQL operation is not providing an Engine or Connection to execute it with, so these two parts of the application are not communicating properly. At the simplest level, you execute statements via 'engine.execute(sql)'. But if you tell a SQL statement or ORM object to execute itself, it looks for an engine/connection in the following order: - 'bind' argument to the method - engine bound to the session (set via sessionmaker options), *if* the operation was invoked from a session object - engine bound to the metadata (set via 'metadata.bind = engine' or 'MetaData(engine)' If it can't find an engine in any of these, it'll fail with this error. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
