Christian Theune wrote:
Hmm. Is it possible to implement some option to turn this off?
I just checked in the ability to use HTTP_TRACEBACK_STYLE to control the appearance of tracebacks in non-debug mode errors: '' (default): Place it in an HTML comment 'none': Omit it 'plain': Include it as plain text just as in debug mode. 'js': Show a § that expands into the traceback when clicked. Cheers, Evan @ Zope
Evan Simpson wrote:
Christian Theune wrote:
Hmm. Is it possible to implement some option to turn this off?
I just checked in the ability to use HTTP_TRACEBACK_STYLE to control the appearance of tracebacks in non-debug mode errors:
'' (default): Place it in an HTML comment 'none': Omit it 'plain': Include it as plain text just as in debug mode. 'js': Show a § that expands into the traceback when clicked.
I thought Shane was working on this in his 'better tracebacks' branch? The fact is that the tracebacks should _never_ be appended by some process outside standard_error_message. If people want tracebacks, and there's _lots_ of different ways people want tracebacks, the should add them explicitly in standard_error_message. That said, the default standard_error_message may want to include the options you have above. cheers, Chris - DWIM never does what you want ;-)
Hi. * Chris Withers <chrisw@nipltd.com> [020316 09:40]:
I thought Shane was working on this in his 'better tracebacks' branch?
The fact is that the tracebacks should _never_ be appended by some process outside standard_error_message.
granted. ;)
If people want tracebacks, and there's _lots_ of different ways people want tracebacks, the should add them explicitly in standard_error_message. That said, the default standard_error_message may want to include the options you have above.
Yes. But actually (I took a look in the LoginManager code - and it seems as if he is not directly guilty that the traceback shows up, when the login screen is raisen) having a commented traceback in all pages is better then having an uninfluencable § dangling around, which actually makes applications unsellable. (I am currently involved in a kind of competition between web application tools at my university, and i want to let zope blink and shine in its best manner.)
cheers,
Chris - DWIM never does what you want ;-)
So it should be called IDWYM, otherwise it is right ... it does what it means ... ;) Greetings Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
* Dieter Maurer <dieter@handshake.de> [020316 21:50]:
Chris Withers writes:
The fact is that the tracebacks should _never_ be appended by some process outside standard_error_message. The tracebacks are very helpful in debug mode. I would like they stay as default in this mode.
Dieter
Yes. Actually this is absolutely not question. My only intention was, to be able to hide the tracebacks from my users/customers in production mode. Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
Dieter Maurer wrote:
Chris Withers writes:
The fact is that the tracebacks should _never_ be appended by some process outside standard_error_message. The tracebacks are very helpful in debug mode. I would like they stay as default in this mode.
As I said, the default (and built in) standard_error_message objects should behave exactly as they did. All I'm saying is that there shouldn't be some external process completely outside an application programmers control (or controllable using some nasty hacky environment variable) that defines this behaviour. We have a wonderful templating language now, and w eshould use it for solving these kinds of problems ;-) cheers, Chris
participants (4)
-
Chris Withers -
Christian Theune -
Dieter Maurer -
Evan Simpson