Some observations
Ole Laursen
I'm new to Tornado. Some observations:
1) Error handling. There's no mention in the documentation of what
happens if the client walks away during an async call. I wrote a
little test application, I can see that you actually get an exception
if you try to write to a closed request. This seems backwards, I can't
really think of a situation where you actually want to know whether a
client receives the bytes - in any case, I don't understand why it
would be default behaviour for a web framework.
I guess you're supposed to check self.request.stream.closed() and that
you can add an error handler with
self.request.stream.set_close_callback(). Maybe they should be
promoted a bit more, or the functionality even integrated into the
asynchronous decorator? It seems to me that you can't write correct
code without them at all.
2) There's no hint in the walkthrough that the database stuff will
actually block the whole process. Didn't expect otherwise, but I think
people who are not familiar with the paradigm might be unpleasantly
surprised?
3) Buffer handling in iostream.py uses concatenation. This is O(n^2)
in the number of writes, I think. Longer explanation
http://www.skymind.com/~ocrow/python_string/. Maybe it doesn't matter
here, it just puzzled me.
4) I was looking for the reverse of prepare(), a method to tear down
anything setup in prepare. Hm, maybe that's just finish(), I need to
call the base class method too, though.
Just thought I would post them in case they are useful,
Ole
Ernesto
questions too:
1) Error handling. It would be nice to see the error message and
stacktrace in the error page, not by default, but maybe by overriding
web.get_error_html() so I can see the relevant info immediately.
2) Development mode. Maybe I'm missing something, but it was tedious
for me to restart the server after every change in the code, so I
wrote a "watchdog" that restarts my app when a change is detected in a
given path.
3) I keep getting the following message in both, an ubuntu server and
my mac:
Exception RuntimeError: 'maximum recursion depth exceeded while
calling a Python object' in <type 'exceptions.RuntimeError'> ignored
Any ideas?
4) I could not assign a variable in a template. Am I missing something
here, too?
Those are my thoughts so far, having developed a Tornado application
during this last week.
Regards,
On 22 ene, 13:59, Ole Laursen <o...@iola.dk> wrote:
> Hi!
>
> I'm new to Tornado. Some observations:
>
> 1) Error handling. There's no mention in the documentation of what
> happens if the client walks away during an async call. I wrote a
> little test application, I can see that you actually get an exception
> if you try to write to a closed request. This seems backwards, I can't
> really think of a situation where you actually want to know whether a
> client receives the bytes - in any case, I don't understand why it
> would be default behaviour for a web framework.
>
> I guess you're supposed to check self.request.stream.closed() and that
> you can add an error handler with
> self.request.stream.set_close_callback(). Maybe they should be
> promoted a bit more, or the functionality even integrated into the
> asynchronous decorator? It seems to me that you can't write correct
> code without them at all.
>
> 2) There's no hint in the walkthrough that the database stuff will
> actually block the whole process. Didn't expect otherwise, but I think
> people who are not familiar with the paradigm might be unpleasantly
> surprised?
>
> 3) Buffer handling in iostream.py uses concatenation. This is O(n^2)
> in the number of writes, I think. Longer explanationhttp://www.skymind.com/~ocrow/python_string/. Maybe it doesn't matter
Stanislav
reload files by itself.
apit
On Jan 22, 9:24 pm, Ernesto <panquetofo...@gmail.com> wrote:
> 1) Error handling. It would be nice to see the error message and
> stacktrace in the error page, not by default, but maybe by overriding
> web.get_error_html() so I can see the relevant info immediately.
i change django debug view a little bit so it can be used in tornado
by exactly what you said, overriding get_error_html()
http://gist.github.com/284705
error page will be like http://dl.dropbox.com/u/355670/tmp/errorpage.png
> 4) I could not assign a variable in a template. Am I missing something
> here, too?
{% set var = expression %}
Ernesto Mendoza Blanco
Ernesto
