That's what I would think, but it doesn't seem to work. The header and footer work just fine, but not the standard_error_message. For example, I modified the root standard_error_message to contain the words "This is the root". Then created a folder called Testing, copied the same standard_error_message document into that folder and added the words "This was copied from..." in the beginning of the doc. I even restarted the server, just to be safe. When I still went to http://server/Testing/badfile, I got the error message from the root. That's why I figured, perhaps, when looking for the 'badfile', the namespaces were searched all the way down the tree. When it didn't find it anywhere, it just printed the error message from where it ended up, which was at the root. Makes sense to me.. Course I'm not sure how it all really works internally. -Ray ----- Original Message ----- From: "Christian Scholz" <cs@comlounge.net> To: "Ray" <zopelist@circle17.com> Sent: Monday, May 01, 2000 6:17 PM Subject: Re: [Zope] standard_error_message
Hi!
On Mon, May 01, 2000 at 05:49:24PM -0600, Ray wrote:
Quick question about error messages under Zope 2.1.0 under Linux:
Is it possible to overload the standard_error_message document, or do all errors essentially come from the root of the tree? I'd like to be able to create customized error messages for SiteAccess'd sites, or just different parts of the tree, for that matter.
As far as Aquisition is concerned you should be able to put another standard_error_message document in your folder which is then used (as it's the case with the header and footer as well).
-- christian
Ray, We've experienced exactly the same problem. We were trying to use a property of a folder to email errors to the appropriate person, but some (maybe all, I can't remember, John?) errors always resulted in the root folder's property being used rather than the property of the appropriate folder.
That's why I figured, perhaps, when looking for the 'badfile', the namespaces were searched all the way down the tree. When it didn't find it anywhere, it just printed the error message from where it ended up, which was at the root. Makes sense to me.. Course I'm not sure how it all really works internally.
This sounds entirely plausible. Can anyone from DC comment on this just so we know what's actually happening. This question has cropped up loads on the list but never with any real outcome... cheers, Chris
Chris Withers wrote:
We've experienced exactly the same problem. We were trying to use a property of a folder to email errors to the appropriate person, but some (maybe all, I can't remember, John?) errors always resulted in the root folder's property being used rather than the property of the appropriate folder.
As a temporary solution, you could create a method call std_error_message in yor subfolders and on the toplevel, and have standard_error_message simply be <dtml-var std_error_message> -- Itamar S.T. itamars@ibm.net
As a temporary solution, you could create a method call std_error_message in yor subfolders and on the toplevel, and have standard_error_message simply be
<dtml-var std_error_message>
I have a nasty feeling this might suffer from the same problem :S John, Can you check this out? cheers, Chris
As a temporary solution, you could create a method call std_error_message in yor subfolders and on the toplevel, and have standard_error_message simply be
<dtml-var std_error_message>
I have a nasty feeling this might suffer from the same problem :S
So do I...
John,
Can you check this out?
Sure. I have a couple of things to finish off this morning, but I'll take a look when they're done and report back to the list with my findings. 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.
John Chandler wrote:
As a temporary solution, you could create a method call std_error_message in yor subfolders and on the toplevel, and have standard_error_message simply be
<dtml-var std_error_message>
I have a nasty feeling this might suffer from the same problem :S
So do I...
John,
Can you check this out?
Sure. I have a couple of things to finish off this morning, but I'll take a look when they're done and report back to the list with my findings.
Checked it out like this: / (Zope root) - standard_error_message ( contains just <dtml-var std_error_message> ) - std_error_message ( copy of original standard_error_message ) - test ( folder ) - std_error_message ( contains <html><body><h1>Test error message</h1> </body></html> ) - index_html ( contains <dtml-var does_not_exist> ) I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the normal error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message So... limited success :-) -- Steve Alexander Software Engineer Cat-Box limited
I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the normal error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message
So... limited success :-)
Is it just me or is that irritatingly inconsistent? I can see why this it happening (acquisition and all) but that doesn't make it any more useful :( Chris
Steve Alexander wrote:
Checked it out like this:
/ (Zope root)
- standard_error_message ( contains just <dtml-var std_error_message> ) - std_error_message ( copy of original standard_error_message ) - test ( folder ) - std_error_message ( contains <html><body><h1>Test error message</h1> </body></html> ) - index_html ( contains <dtml-var does_not_exist> )
I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the normal error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message
So... limited success :-)
New experiment: / (Zope root) - standard_error_message -- contains just <dtml-var "_.render(REQUEST.resolve_url(URL+'/std_error_message'))"> - std_error_message ( copy of original standard_error_message ) - test ( folder ) - std_error_message ( contains <html><body><h1>Test error message</h1> </body></html> ) - index_html ( contains <dtml-var does_not_exist> ) I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the test error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message also... I try the url "http://server/test/blarg/foo", and I get the test error message Better! There is just one strangeness. I've changed the text of /std_error_message, but for errors not caught by a std_error_message in a subdirectory, I get some sort of hard-coded error message -- Zope doesn't seem to be calling my root /standard_error_message at all in this case. -- Steve Alexander Software Engineer Cat-Box limited
Steve, 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... 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. 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. 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. Anyone agree? If so then what do we need to do to make this happen? If not, then how should it be done? cheers, Chris PS: "ZOPE: Together we'll crack it!" (for all those who watch UK TV ;-) Steve Alexander wrote:
Steve Alexander wrote:
Checked it out like this:
/ (Zope root)
- standard_error_message ( contains just <dtml-var std_error_message> ) - std_error_message ( copy of original standard_error_message ) - test ( folder ) - std_error_message ( contains <html><body><h1>Test error message</h1> </body></html> ) - index_html ( contains <dtml-var does_not_exist> )
I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the normal error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message
So... limited success :-)
New experiment:
/ (Zope root)
- standard_error_message -- contains just <dtml-var "_.render(REQUEST.resolve_url(URL+'/std_error_message'))">
- std_error_message ( copy of original standard_error_message ) - test ( folder ) - std_error_message ( contains <html><body><h1>Test error message</h1> </body></html> ) - index_html ( contains <dtml-var does_not_exist> )
I try the url "http://server/blarg", and I get the normal error message I try the url "http://server/test/blarg", and I get the test error message I try the url "http://server/test/index_html", and I get the test error message I try the url "http://server/test", and I get the test error message
also... I try the url "http://server/test/blarg/foo", and I get the test error message
Better!
There is just one strangeness. I've changed the text of /std_error_message, but for errors not caught by a std_error_message in a subdirectory, I get some sort of hard-coded error message -- Zope doesn't seem to be calling my root /standard_error_message at all in this case.
-- Steve Alexander Software Engineer Cat-Box limited
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.
John Chandler wrote:
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.
I agree that Zope's error handling pages should work as John has described in his message. However, I've found that the following as /standard_error_message seems to meet Chris' original requirement of overriding error methods in folders in the heirarchy. This is the root /standard_error_message -------- <dtml-try> <dtml-var "_.render(REQUEST.resolve_url(URL+'/std_error_message'))"> <dtml-except> <html> <body> <h1>Standard error message</h1> </body> </html> </dtml-try> -------- Custom error messages go in std_error_message in each folder. When an error occurs, it is handled by the nearest std_error_message up the heirarchy. I haven't tested it for errors in std_error_message yet. If this works for you, I'll make it into a HowTo. -- Steve Alexander Software Engineer Cat-Box limited
However, I've found that the following as /standard_error_message seems to meet Chris' original requirement of overriding error methods in folders in the heirarchy.
[Snip sample code]
If this works for you, I'll make it into a HowTo.
If you do, let me know when it's published and I'll reference it from my document on customising standard_error_message Cheers, 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.
Apologies for my current posting frenzy ;-) Normal service will be resumed shortly...
However, I've found that the following as /standard_error_message seems to meet Chris' original requirement of overriding error methods in folders in the heirarchy.
This is the root /standard_error_message -------- <dtml-try> <dtml-var "_.render(REQUEST.resolve_url(URL+'/std_error_message'))"> <dtml-except> <html> <body> <h1>Standard error message</h1> </body> </html> </dtml-try> --------
Custom error messages go in std_error_message in each folder. When an error occurs, it is handled by the nearest std_error_message up the heirarchy.
Cheers. This is pretty close, I've just tried it out with suitably vile colours to distinguish which instance of standard_error_message is being used, and it does do the trick with everything except an invalid URL (404 errors). For example a std_error_message in folder /foo/bar won't get used if the requested URL is for /foo/bar/fred, but that shouldn't be too difficult to solve by stepping back until something valid is found... I would guess.
I haven't tested it for errors in std_error_message yet.
What you get is something which looks like a hybrid of the root standard error page embedded within the default error page... You can also use standard_error_message instead of std_error_message - they both have the same desired effect. Cheers, 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.
There is just one strangeness. I've changed the text of /std_error_message, but for errors not caught by a std_error_message in a subdirectory, I get some sort of hard-coded error message -- Zope doesn't seem to be calling my root /standard_error_message at all in this case.
I've found this happens if there's a DTML error in the standard_error_message. Although it doesn't appear to report the error in the error message, the fact it's come up is usually a clue :-/ 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.
Is this Zope bug collector worthy? Chris
We've experienced exactly the same problem. We were trying to use a property of a folder to email errors to the appropriate person, but some (maybe all, I can't remember, John?) errors always resulted in the root folder's property being used rather than the property of the appropriate folder.
I've just double-checked this and yep, it appears to be all errors using only the root. This is on 2.1.4, I'll check 2.1.6 shortly... If I have a standard_error_message in root and a property 'ErrorTo' in root, standard_error_message is called from everywhere in the site and uses the property in root. So far so good... If I delete the property from root, the standard_error_message is used throughout the site, but the property doesn't exist. Again, so far so good... If I add the ErrorTo property back, but to a different folder and get an error from within that folder, the root standard_error_message is still used, but the property isn't found. If I add an ErrorTo property back to root, it is used. If I now add a different standard_error_message to that folder, and get an error, the root standard_error_message is still used with the root property.
That's why I figured, perhaps, when looking for the 'badfile', the namespaces were searched all the way down the tree. When it didn't find it anywhere, it just printed the error message from where it ended up, which was at the root. Makes sense to me.. Course I'm not sure how it all really works internally.
This sounds entirely plausible. Can anyone from DC comment on this just so we
Yep, that matches my personal experiences... 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.
participants (5)
-
Chris Withers -
Itamar Shtull-Trauring -
John Chandler -
Ray -
Steve Alexander