I think John has chucked this in the collector. Personally I feel this whole area a needs a thorough going over by someone who really understands it...
I've submitted it. Actually, in doing so I noticed someone had submitted this back last August as a bug, and it was acknowledged as such with the conclusion that it would be fixed for Zope 2.0b5. I can either conclude it wasn't fixed, or it's b0rken again...
In the meantime, what would we *like* to have happen?
My vote is:
The nearest standard_error_message up the acquisition tree from where the error occurs should be called, and in the context of the folder/container in which that standard_error_message resides, for things like properties and acquired object.
Agreed. This allows separate sites running from different folders to retain their own distinct look and feel, as well as allowing different folder owners to identified and contacted as errors occur.
If this standard_error_message can't handle the error or is itself faulty and causes an error then the next one up in the aquisition tree should be used, with the rules above applied.
Erm, I agree in principle. However, the current error page doesn't flag the fact that it contains an error (erk, confusing sentence warning...), but the hard coded error page is sufficiently different to the existing one as to be a useful signal for this problem. I like the treatment you mention a lot, but it would be useful to know when an error page has generated an error itself somehow.
If no working/suitable standard_error_message's are found then Zope's hard coded error message (which Steve was getting below...) should be thrown back as a last resort.
Okay. I guess in practice, error pages along the acquisition tree are going to be sufficiently different to the developers at least as to make it reasonably clear if one has failed and another has taken over.
Anyone agree? If so then what do we need to do to make this happen?
Well, we can live with it at the moment, I've listed the bug as needing to be fixed for the next release but not immediately, but it's something that would be very useful to have running as soon as possible. John -- John Chandler / Software Developer / New Information Paradigms Ltd [ Linux in the office, AmigaOS in the home, PalmOS in the pocket ] ------------------------------------------------------------------------ The opinions above aren't those of my company... ...but then, they aren't really mine either.