Among the changes:
* New unique argument to header keeps duplicate headers from being printed
* New function datestr prints out datetime objects in a nice way
* You can tell it to listen on a fastcgi socket
* db_printing now quotes SQL better
* web.input('foo') automatically returns badrequest if foo isn't sent
* input takes a _method argument to get just GET variables
But my favorite three are flush, changequery, and background. They're
a little harder to explain, so I'll give examples:
## flush
def GET(self):
web.header('Content-Type', 'text/html')
yield web.flush()
print "This now gets printed immediately."
time.sleep(5)
print "As does this."
Without web.flush(), users would see nothing for five seconds. Now
they see things as you print them. (Be sure to yield web.flush, not
just call it, and be sure to do it between the headers and the body.)
## changequery
sort by:
<a href="$changequery(s='date')">date</a> |
<a href="$changequery(s='rel')">relevance</a>
(Assuming changequery is web.changequery.) This prints out links to
the current page with its current URL arguments, but with the query
argument s changed to point to 'date' or 'rel' as necessary.
## background
This is my favorite. Imagine you have a request that does something
that takes a while, like a complicated computation or grabbing
something from the network. You don't want to force the user to sit
and wait -- they might think nothing is happening and submit the
request again or get annoyed and leave. The function background is a
little function decorator you can use. It'll run your normal function
in a background thread and redirect the user to a page with a unique
name that they can use to keep up to date on its status by reloading.
class index:
@web.background
def GET(self):
web.header('Refresh', '1')
web.header('Content-Type', 'text/plain')
print "This could take a while."
for i in xrange(2):
time.sleep(5)
print 'Even longer.'
web.seeother('/done')
(Normally, of course, you'd probably want to use a <meta refresh>
that's supported by more browsers inside your HTML.)
So what this does is it gives users a page that updates every second
showing the status of this function, eventually redirecting them to
/done when the function is complete. The whole page just works with no
modifications to the code other than the decorator and the refresh.
Enjoy and let me know about any problems you hit.
Is there a way to set a default header for all requests? Would be
useful for setting the character encoding.
>An updated version of web.py is up at for your testing pleasure:
>
>http://webpy.org/svn/web.py
>
>Among the changes:
> * New unique argument to header keeps duplicate headers from being printed
> * New function datestr prints out datetime objects in a nice way
> * You can tell it to listen on a fastcgi socket
> * db_printing now quotes SQL better
> * web.input('foo') automatically returns badrequest if foo isn't sent
> * input takes a _method argument to get just GET variables
>
>But my favorite three are flush, changequery, and background.
>
>
[snip]
>Enjoy and let me know about any problems you hit.
>
>
webpy used to run fine with python 2.3. It does not anymore :( and I do
not see it mentioned among the changes. Further the version 0.137 seems
to be packaged in debian requiring >=2.3 and < 2.4 which is clearly wrong.
There seem to be two problems:
1) 'set' detection with 'has_key' I've reported earlier (deleting it
fixes the problem)
2) a single use of @backgrouder which I believe is also one line fix
Zbynek
--
http://zw.matfyz.cz/ http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic
yeah I noticed this. I think I manully installed it without using the
debian install script. The only requirement for python < 2.4 was in the
script itself. So install webpy manually. Aside from the python code
the install also included documentation. So either ignore the documents
or install them as well.
I'm currently running webpy without problem using ....
*webpy 0.137
*Ubuntu 5.10 (debian)
*apache 2.0.54
*mod_python 3.1.3
*python 2.4.2
'... debian requiring >=2.3 and < 2.4 which is clearly wrong. ...'
third party debian script, so you cant blame aaron for that one. Let us
know if you have trouble.
Regs PR
The default interpreter is 2.3 so it's built for that only for the
moment. I could make 2.4 packages.
Well, I don't know whose responsibility it is. I was just trying to
point out that 0.137 does not work with python2.3 && debian package of
webpy depends on python2.3.x only. Woudn't be better to build webpy
package depending on python2.3>= only? And leave out the python2.4<
part? AFAIK there is nothing in webpy that needs to be "built" against a
specific python version, is there?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358900
Python packaging is a bit a of a pain. :)
Working on it...