url_for with controller argument does not prepend prefix
Hi,
I use the PrefixMiddleware and usually url_for generates good urls for me:
h.url_for('/documents', action='foo')
'/bar/documents?action=foo'
however when the controller parameter is present, it doesn't:
h.url_for(controller='/documents', action='foo')
'/documents/foo'
The docs [1] say:
The following rules are used to determine when and how to keep the
current requests parameters:
* If the controller is present and begins with ‘/’, no defaults are
used
* If the controller is changed, action is set to ‘index’ unless
otherwise specified
I don't know what 'no defaults are used' means, but also 'documents'
returns the same result:
h.url_for(controller='documents', action='foo')
'/documents/foo'
Is that a bug or just the expected behavior? In the latter case, can you
explain to me why it behaves like this? And how I could have figured out
that myself?
fs
[1] http://pylonshq.com/docs/en/0.9.7/thirdparty/routes/#module-routes.util
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@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: url_for with controller argument does not prepend prefix
some nice people on the IRC channel pointed out that url_for is deprecated and I should use pylons.url However pylons.url does not seem to obey my PrefixMiddleware configuration. How can I make pylons.url aware of the configuration? Or is that just a stupid thing on my side? fs -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: url_for with controller argument does not prepend prefix
On Sun, May 2, 2010 at 5:00 AM, Felix Schwarz
felix.schw...@oss.schwarz.eu wrote:
some nice people on the IRC channel pointed out that url_for is deprecated
and I should use pylons.url
However pylons.url does not seem to obey my PrefixMiddleware configuration.
How can I make pylons.url aware of the configuration? Or is that just a
stupid thing on my side?
I've about had it with Routes. Its syntax allows too much ambiguity,
and the older docs have sent people in all sorts of questionable
directions. I'm half inclined to release the Routes2/Routes-exp code
under a different name, with no ambiguous syntaxes or backward
compatibility allowed. As if I had time to.
The docs you're looking at are for 0.9.7, which was released over a
year ago. Since then there have been advances in Routes and best
practices. It looks like Pylons 1.0 needs to be released sooner
rather than later, to tighten up the docs. The current Routes docs
are here: http://routes.groovie.org/ . Then
unfinished-but-better-than-0.9.7 Pylons docs are here:
http://pylonshq.com/docs/en/1.0/ .
The best way to generate routes is by name:
# Named generation
map.connect(documents, /documents/{action}, controller=documents)
url(documents, action=foo) = /prefix/documents/foo
In this case, the first positional arg is the route name, not the
controller per se.
For external URLs and special cases you can use a literal URL:
# External URL (no route for it)
url(/documents, action=foo) = /prefix/documents?action=foo
This is like your first example. The first arg begins with a slash, so
it's taken as a literal URL rather than a name. It does not match any
route, so there are no path variables or extra variables (defaults)
to consider. All keyword args are converted to query parameters. Of
course, Pylons does not look for the action in a query parameter, so
it would not be able to process this URL.
# Generic /controller/action URL
map.connect(/{controller}/{action})
url(controller=documents, action=foo) = /prefix/documents/foo
This is less reliable than named generation, but it has been
traditional in Pylons, and it's safe as long as there's only one route
that could plausably match.
If any of the above don't handle the prefix properly, it's probably a
bug so let us know.
The [old] docs say:
The following rules are used to determine when and how to keep the
current requests parameters:
* If the controller is present and begins with ‘/’, no defaults are
used
No defaults are used means it will ignore the extra variables in the
route definition (which were then called defaults).
I'm not sure if the statement is still true, or if it ever was. I
never considered putting a slash in a controller variable
(controller=/documents)
* If the controller is changed, action is set to ‘index’ unless
otherwise specified
This is no longer the default case. If the action is not specified
either in the route definition or in the generation args, no action
will be passed to Pylons, which will raise an error.
--
Mike Orr sluggos...@gmail.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-disc...@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.
Cron events in a Pylons app?
What would be the recommended way to implement cron-triggered events but in the context and framework of a Pylons app? I suppose the most straightforward way would be to implement a controller and call it via localhost with, say, curl, minding of course all the security aspects of such a public handler. Is there a better way, though? Thanks, Vlad -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: Programmatically shutting down Pylons server
On Apr 30, 2010, at 7:12 AM, Alec Munro wrote: Ok, the problem seems to be that fact that the file being run is a batch file. I printed out the resulting java call, and used that instead, and it works. However, now I need to modify my script to handle some of what jython.bat does. Ah well. It's probably just an oddity of Windows, maybe it kills the bat process but the child process is unaffected. The bat file runs java via: cmd.exe /c exit /b java. Maybe there's another way to invoke it that would work better? Eventually the Jython .bat file launcher will be replaced with a native .exe launcher -- if not by Jython 2.5.2 then likely the next release. That should solve this issue among other things: http://bugs.jython.org/issue1491 -- Philip Jenvey -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: Cron events in a Pylons app?
Thanks! Vlad On 05/02/10 21:51, Gael Pasgrimaud wrote: On Sun, May 2, 2010 at 9:46 PM, Haron Media i...@haronmedia.com wrote: What would be the recommended way to implement cron-triggered events but in the context and framework of a Pylons app? I suppose the most straightforward way would be to implement a controller and call it via localhost with, say, curl, minding of course all the security aspects of such a public handler. Is there a better way, though? You can use paster request config.ini /path See paster help request: Usage: paster request [options] CONFIG_FILE URL [OPTIONS/ARGUMENTS] Run a request for the described application This command makes an artifical request to a web application that uses a paste.deploy configuration file for the server and application. Use 'paster request config.ini /url' to request /url. Use 'paster post config.ini /url data' to do a POST with the given request body. If the URL is relative (doesn't begin with /) it is interpreted as relative to /.command/. The variable environ['paste.command_request'] will be set to True in the request, so your application can distinguish these calls from normal requests. Note that you can pass options besides the options listed here; any unknown options will be passed to the application in environ['QUERY_STRING']. Options: -h, --helpshow this help message and exit -v, --verbose -q, --quiet -n NAME, --app-name=NAME Load the named application (default main) --config-var=NAME:VALUE Variable to make available in the config for %()s substitution (you can use this option multiple times) --header=NAME:VALUE Header to add to request (you can use this option multiple times) --display-headers Display headers before the response body -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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.
