Routes not seeing _method when multipart=True
Hello, As the subject tells, Routes doesn't alter a POST request to if an alternate _method was specified in the POST data. I've opened a ticket for that: http://routes.groovie.org/trac/routes/ticket/64 Regards, -- Alexandre CONRAD --~--~-~--~~~---~--~~ 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 not seeing _method when multipart=True
Sorry, I just realized there was a Routes 1.7.1 which seems to have this issue fixed already. Alexandre Conrad wrote: Hello, As the subject tells, Routes doesn't alter a POST request to if an alternate _method was specified in the POST data. I've opened a ticket for that: http://routes.groovie.org/trac/routes/ticket/64 Regards, -- Alexandre CONRAD --~--~-~--~~~---~--~~ 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: WebHelpers plans
jQuery. Nobody uses Prototype or Scriptaculous anymore, jQuery's simplicity fits in well with Pylons, and I find jQuery more Pythonic than even Mochikit. I haven't used Mochikit so far, but having used both prototype/ scriptaculous and jQuery on two recent projects, I *highly* recommend jQuery. Anyway, I don't like this link_to_remote stuff since I try my best to make my js unobtrusive. I like jquery, too. I've made jquery widget for TG and some 'link_to_remote/ periodically_call_remote/form_remote_tag' widgets to more pythonic convention (twisted naming style) as 'addCallback/addPeriodBack/ addFormback'. http://pypi.python.org/pypi/jquery BTW, jquery has Ext-equivalent UI plugins as well. http://ui.jquery.com/ -- Fred --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Targeting the current release or trunk
Greetings, I've got some projects coming up that I'm currently planing to develop using Pylons. I follow this mailling list and it seems there are some pretty big framework changes coming to 0.9.7. Do the developers recommend working with the current trunk code or sticking with the release version and then updating later? Is there a current time-frame for 0.9.7s release? Thanks, - Justin --~--~-~--~~~---~--~~ 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: WebHelpers plans
I see Pylons users have several favorite Javascript libraries, including MochiKit which wasn't mentioned initially. JQuery seems to get the most votes. However, we still haven't decided so keep the feedback coming. One critical factor is maintainers. We'll need a maintainer for each Javascript library that is added. So the best way to get a Javascript library included is to volunteer to maintain it. There hasn't been much feedback about the rest of WebHelpers. Does that mean I can change anything at all and y'all won't find it too burdensome to change your apps? -- 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 -~--~~~~--~~--~--~---
[bug] beaker help doesn't work in python shell
Hi, When I try to display the help for some beaker subpackages in a Python interpreter, I get the following error: import beaker.middleware help(beaker.middleware) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/site.py, line 351, in __call__ return pydoc.help(*args, **kwds) File /usr/lib/python2.5/pydoc.py, line 1646, in __call__ self.help(request) File /usr/lib/python2.5/pydoc.py, line 1690, in help else: doc(request, 'Help on %s:') File /usr/lib/python2.5/pydoc.py, line 1481, in doc pager(title % desc + '\n\n' + text.document(object, name)) File /usr/lib/python2.5/pydoc.py, line 324, in document if inspect.ismodule(object): return self.docmodule(*args) File /usr/lib/python2.5/pydoc.py, line 1072, in docmodule contents.append(self.document(value, key, name)) File /usr/lib/python2.5/pydoc.py, line 325, in document if inspect.isclass(object): return self.docclass(*args) File /usr/lib/python2.5/pydoc.py, line 1173, in docclass classify_class_attrs(object)) File /usr/lib/python2.5/pydoc.py, line 179, in classify_class_attrs return map(fixup, inspect.classify_class_attrs(object)) File /usr/lib/python2.5/inspect.py, line 249, in classify_class_attrs homecls = getattr(obj, __objclass__, None) File /usr/lib/python2.5/site-packages/Paste-1.6-py2.5.egg/paste/registry.py, line 125, in __getattr__ return getattr(self._current_obj(), attr) File /usr/lib/python2.5/site-packages/Paste-1.6-py2.5.egg/paste/registry.py, line 182, in _current_obj 'thread' % self.name__) TypeError: No object (name: Cache Manager) has been registered for this thread By the way, the beaker package doesn't have a __version__ attribute. Looking at the site-packages dir, the installed version here is 0.7.5. Regards Antoine. --~--~-~--~~~---~--~~ 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: WebHelpers plans
I'm +1 for Dojo. The base library is excellent. - Justin On Jan 10, 2008 12:38 PM, Mike Orr [EMAIL PROTECTED] wrote: I see Pylons users have several favorite Javascript libraries, including MochiKit which wasn't mentioned initially. JQuery seems to get the most votes. However, we still haven't decided so keep the feedback coming. One critical factor is maintainers. We'll need a maintainer for each Javascript library that is added. So the best way to get a Javascript library included is to volunteer to maintain it. There hasn't been much feedback about the rest of WebHelpers. Does that mean I can change anything at all and y'all won't find it too burdensome to change your apps? -- 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 -~--~~~~--~~--~--~---
Re: Where in the reference docs is h.url_for (and other 'globals')?
On Tue, 2008-01-08 at 21:46 -0500, Yannick Gingras wrote: John_Nowlan [EMAIL PROTECTED] writes: Aren't docs supposed to help alleviate the need to go to the source? In `paster shell`, in a template, or in a controller action, you can do: print h.url_for.__module__ So you're agreeing with him? 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 -~--~~~~--~~--~--~---
how to pass id through form_remote_tag?
I've tried a couple things to no avail:
${h.form_remote_tag(url='/ui/select_results', update=select_results,
id=inputform)}
id just gets ignored here it seems
and
${h.form_remote_tag(url='/ui/select_results', update=select_results,
html={id:inputform})}
throws a SyntaxException.
Any ideas?
thx
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: how to pass id through form_remote_tag?
Okay, posted too soon, this works:
%
s = h.form_remote_tag(html={id:inputform}, url='/ui/select_results',
update=select_results)
%
${s}
Seems mako doesn't like the {} for the dict inside a ${...}
m
On Thu, Jan 10, 2008 at 12:22:21PM -0800, Matt wrote:
I've tried a couple things to no avail:
${h.form_remote_tag(url='/ui/select_results', update=select_results,
id=inputform)}
id just gets ignored here it seems
and
${h.form_remote_tag(url='/ui/select_results', update=select_results,
html={id:inputform})}
throws a SyntaxException.
Any ideas?
thx
m
--
Matt Billenstein
[EMAIL PROTECTED]
http://www.vazor.com/
--~--~-~--~~~---~--~~
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: Targeting the current release or trunk
On Jan 10, 2008 7:32 AM, Justin [EMAIL PROTECTED] wrote: Greetings, I've got some projects coming up that I'm currently planing to develop using Pylons. I follow this mailling list and it seems there are some pretty big framework changes coming to 0.9.7. Do the developers recommend working with the current trunk code or sticking with the release version and then updating later? Is there a current time-frame for 0.9.7s release? 0.9.7 is scheduled for March, hopefully before PyCon. I've been nudging Ben to release an alpha because part of the work has been done. At this point it's a toss-up whether to use 0.9.6.1 or dev for an app to be released in the six-week-or-longer timeframe. The changes to Pylons core are mostly housekeeping and don't affect application code much. They have been stable for a few weeks, and tested on my application at least. Keep an eye on What's New in Pylons 0.9.7 for an explanation of committed changes, and Pylons Roadmap to 1.0 for future plans. http://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779 http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0 Currently if you create a project in dev, it will: - Add the three new required middlewares in middleware.py. (For routing, sessions, and error handling.) [To make the app compatible with both dev and 0.9.6, put an if around these as described in What's New.] - Ask if you want SQLAlchemy and if so, set up the latest greatest configuration in model,py, environment,py, and development.ini. [Should work under 0.9.6 as is.] - Add use_webob=False in middleware.py. If you set this to true, it will use webob.Request and webob.Response, which are more complete and better documented than the older objects. Docs at http://pythonpaste.org/webob. At some point, WebOb will be required. [For 0.9.6 compatibility, use an if to avoid mentioning use_webob in the older version. Also put an if around each access to a WebOb attribute/method, to fall back to the equivalent older method. The most common usage, request.params, is unchanged.] The most disruptive changes will be in Routes, WebHelpers, and templating. but those are still vaporware so it doesn't matter which version of Pylons you target at this time. I'm trying to announce potential changes early so users can anticipate them and isolate those portions of their code. Pylons-dev currently depends on Routes 1.7.1, which is stable and compatible. Don't use Routes-dev because it has a serious bug (url_for sometimes returns None), and that development branch will be abandoned. Routes 2 will have a different configuration syntax and url_for syntax, but you'll probably be able to use either Routes 2 or Routes 1 with 0.9.7 if you're happy with your existing routes. The main reason to switch to Routes 2 is it will be simpler and more deterministic, making it easier to predict which route will be chosen. WebHelpers changes are totally up in the air, so just use the existing functions for now. Template changes will be limited to the configuration in environment.py, and the render() arguments. I'm not sure if it there will be incompatible changes or not. -- 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 -~--~~~~--~~--~--~---
Re: Where in the reference docs is h.url_for (and other 'globals')?
On Jan 10, 2008 11:50 AM, Cliff Wells [EMAIL PROTECTED] wrote: On Tue, 2008-01-08 at 21:46 -0500, Yannick Gingras wrote: John_Nowlan [EMAIL PROTECTED] writes: Aren't docs supposed to help alleviate the need to go to the source? Yes, the docs need to be improved, especially in the areas of Request/Response attributes, utility functions like abort() and WebHelpers, the decorators, etc. All this work is ongoing. A lot of stuff in the Cookbook belongs in the official docs and will eventually be organized and put there. -- 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 -~--~~~~--~~--~--~---
Re: how to pass id through form_remote_tag?
On Jan 10, 2008 12:27 PM, Matt Billenstein [EMAIL PROTECTED] wrote:
Okay, posted too soon, this works:
%
s = h.form_remote_tag(html={id:inputform}, url='/ui/select_results',
update=select_results)
%
${s}
Seems mako doesn't like the {} for the dict inside a ${...}
That's a Mako bug.
http://www.makotemplates.org/trac/ticket/20
--
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
-~--~~~~--~~--~--~---
RE: Where in the reference docs is h.url_for (and other 'globals')?
It's a good tip. Docs can always be better. Now I owe Yannick some sweat equity on the docs, to try and help make it so. (He says commandingly. Nothing happens. Must be out of lighter fluid.) In `paster shell`, in a template, or in a controller action, you can do: print h.url_for.__module__ So you're agreeing with him? --~--~-~--~~~---~--~~ 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: how to pass id through form_remote_tag?
On Thu, Jan 10, 2008 at 12:49:44PM -0800, Mike Orr wrote:
On Jan 10, 2008 12:27 PM, Matt Billenstein [EMAIL PROTECTED] wrote:
Okay, posted too soon, this works:
%
s = h.form_remote_tag(html={id:inputform}, url='/ui/select_results',
update=select_results)
%
${s}
Seems mako doesn't like the {} for the dict inside a ${...}
That's a Mako bug.
http://www.makotemplates.org/trac/ticket/20
Now makes sense why I see the docs using dict(x=blah):
${h.form_remote_tag(html=dict(id=inputform), url='/ui/select_results',
update=select_results)}
to get around this bug.
Also, any ideas why I can't specify the name here too? I get:
exceptions.TypeError: tag() got multiple values for keyword argument 'name'
When doing:
${h.form_remote_tag(html=dict(name=inputform), url='/ui/select_results',
update=select_results)}
thx
m
--
Mike Orr [EMAIL PROTECTED]
--
Matt Billenstein
[EMAIL PROTECTED]
http://www.vazor.com/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
