Tag: zope4

Once upon the time there was Earl Zope II. A wise guy was telling him that his world will come to an end. He found out that this was true that he had only some years to prepare to immigrate to the Python 3 wonderland.

His preparation was successful: He got past the strict immigration check and has now a beta permission to stay in the Python 3 wonderland. Earl Zope really likes his new home, but he is missing some friends. Most of them are still at the border of Python 3 wonderland and have to go through the immigration process. Earl Zope would be pleased to offer the same service to his friends as in the old Python 2 land.

To get the final permission to stay in Python 3 wonderland Earl Zope needs to build up trust in his abilities and his stability by other inhabitants and old friends. Therefore, he has to show, that he can work with old and new friends in the Python 3 wonderland.

Zope 4 Welcome sprint – 16th until 18th May 2018

Earl Zope invites you to join a sprint with some helpful people to welcome Zope 4 and his friends in Python 3 wonderland. This means: Bring in your Zope 2 based application and we look together how to port it to Zope 4 or even Python 3. That’s why we call the sprint “Zope 4 Welcome sprint”. You can also help by posting issues or even pull requests about your migration attempts.

The sprint will be located in Halle (Saale), Germany. We meet there from Wednesday, 16th till Friday, 18th of May 2018. Please join us via Meetup even if you are planning to work from remote. You will find more detailed and updated information about the sprint there, too.

TL;DR: You have to write an exception view in file system code which is rendered when an exception occurs.

History

If an exception occurred in Zope 2 the standard_error_message (an object in the ZODB) was rendered. This way the error page could be customised through the web.

When using a WSGI server on Zope 2 the standard_error_message is no longer used. The exceptions have to be handled in a WSGI middleware. (This is a sub-optimal solution as the middleware is not run in the same execution context where the exception occurred.)

Thats why error handling changed again in Zope 4: Like Zope 3 (aka BlueBream) Zope 4 tries to lookup an exception view if an exception occurs. If the lookup succeeds (aka there is an exception view registered for the current exception) this view is rendered as response. This approach allows different views for different exceptions. The standard_error_message is even gone when installing Zope 4 from scratch.