This proposal is dead-on to make the errors more accessible and customizable. This is the solution to some of my previous error_message threads. How do we move this from proposal to project? Why not start with a less ambitious first phase of opening up Exceptions control as a "product". How about a Folder attribute or a standard_error_message controller? Then with time ready it for the core. -Trevor

-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Andre Schubert Sent: Monday, December 03, 2001 11:09 AM To: seb bacon Cc: zope Subject: Re: [Zope-dev] Zope Exceptions and translation

Hi,

yes it is a big job, but i started at all form-based exceptions, because the members of our websites can manage many things over web-forms, thats why i tried to patch all HTTPResponse-exceptions with writing a product that patches the correspondend functions, further i patched Converters.py so that it returns german error_values. Thats the work i have done and it seems to work for me. All i want is a Product which catches as many exceptions as possible and translate them into, for me, german. I also thought that i can design the product as like as zzlocale, thats its easy to translate into other languages.

I dont want to hack the sources, i want a Product but its hard to program all the exceptions.

thanks as

seb bacon schrieb:

...

You're certainly right, but it would be a big job. In fact I recently started a proposal on the subject (bare bones). Please add to it! Especially the requirement for i18n.

http://dev.zope.org/Wikis/DevSite/Proposals/ClassBasedExceptions

What and how should it add???

...

seb

* Andre Schubert <andre.schubert@geyer.kabeljournal.de> [011203 15:10]:

...

Hi all,

I'am looking for several products to translate zope-site into german. I have found ZBabel and it works very fine for normal websites. It always works fine in the standard_error_message if there is an error_value and an error_type. But it doesnt work if i get an string exception, because the

error_value

...

...

is an complete html-site. Therefore i tryed to patch some Exceptions in HTTPResponse to raise an class-Exception and a short string as error_value. The problem i see is that all exceptions in zope are raised in many defferent places and thats very difficult to patch them or to make them translation-able. I think it is a good way to change all string-exceptions like these in HTTPResponse to class-exceptions and the error_value to a normal description. With these changes the standard_error_message could be raised and there is an ability to translate the error_value. Do i think in the right way or did i missing any facts

thanks as

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

--

[] j a m k i t

seb bacon T: 020 7749 7218 F: 020 7739 8683 M: 07968 301 336 W: www.jamkit.com

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

From: Trevor Toenjes <zope@toenjes.com>

This proposal is dead-on to make the errors more accessible and customizable. This is the solution to some of my previous error_message threads.

How do we move this from proposal to project?

We need to define the scope very clearly. Please add your ideas to the Wiki :)

Why not start with a less ambitious first phase of opening up Exceptions control as a "product". How about a Folder attribute or a standard_error_message controller?

This is a very good idea. One risk is that because it should work with string-based exceptions, it might *encourage* people to continue to work with string-based exceptions. We would also need to fix the 'errors outside html' and 'hardcoded errors' problems as part of the project, I think. seb

Hi, we at ZBabel have to same problems with translating the Exceptions of Products. And my personal best solution is to use the translate-Method direct in the Python-Code which raises the Exceptions. That works for every text directly in the Python Code. Regards Dirk Andre Schubert schrieb:

Hi,

yes it is a big job, but i started at all form-based exceptions, because the members of our websites can manage many things over web-forms, thats why i tried to patch all HTTPResponse-exceptions with writing a product that patches the correspondend functions, further i patched Converters.py so that it returns german error_values. Thats the work i have done and it seems to work for me. All i want is a Product which catches as many exceptions as possible and translate them into, for me, german. I also thought that i can design the product as like as zzlocale, thats its easy to translate into other languages.

I dont want to hack the sources, i want a Product but its hard to program all the exceptions.

thanks as

seb bacon schrieb:

...

You're certainly right, but it would be a big job. In fact I recently started a proposal on the subject (bare bones). Please add to it! Especially the requirement for i18n.

http://dev.zope.org/Wikis/DevSite/Proposals/ClassBasedExceptions

What and how should it add???

...

seb

* Andre Schubert <andre.schubert@geyer.kabeljournal.de> [011203 15:10]:

...

Hi all,

I'am looking for several products to translate zope-site into german. I have found ZBabel and it works very fine for normal websites. It always works fine in the standard_error_message if there is an error_value and an error_type. But it doesnt work if i get an string exception, because the error_value is an complete html-site. Therefore i tryed to patch some Exceptions in HTTPResponse to raise an class-Exception and a short string as error_value. The problem i see is that all exceptions in zope are raised in many defferent places and thats very difficult to patch them or to make them translation-able. I think it is a good way to change all string-exceptions like these in HTTPResponse to class-exceptions and the error_value to a normal description. With these changes the standard_error_message could be raised and there is an ability to translate the error_value. Do i think in the right way or did i missing any facts

thanks as

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

--

[] j a m k i t

seb bacon T: 020 7749 7218 F: 020 7739 8683 M: 07968 301 336 W: www.jamkit.com

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

On Monday, December 3, 2001, at 12:07 PM, Leonardo Rochael Almeida wrote:

Since we are all out complaining about things we'd like to see differently in Zope, let me do my complaining here.

IMO, the string exception problem is one of the worst simptoms of Zope string addiction.

There are way too many parts of Zope that depend on using the right string value. Exceptions and permissions are the worst two, I think.

Zope exceptions should be classes, as seb explained, but ideally the should inherit from a common Zope Exception that is already security declared, so that we can import and catch them in restricted code. I'm tired of writing python scripts that need to do a blind catch because the thing I'm trying to catch is a sligth different form of 'Bad Request' for something as simple as creating an object in a folder that happened to have the same id of an object already there. Any string exception in Zope core or in products should be considered a bug.

Hopefully the publishing machinery will get overhauled enough in Zope 3 to address this. What you're seeing is a long-standing feature of Bobo (aka ZPublisher) that allowed the raising of HTTP 'Exceptions'. When one of these exceptions is raised, the publishing machinery translates it into an appropriate HTTP error code. Since this is such a deep and old feature (written long before class based exceptions were implemented), no one's taken the time to go through and deal with updating them. There are actually a few levels of exceptions possible - standard application level exceptions and the more deliberate protocol based exceptions, such as 'Bad Request', 'Unauthorized', 'Forbidden', etc.

As for permissions, I bet many of you have spent a fair amount of hours debugging a permission problem just to find out that you misspelled or miscapitalized (is that a word?) a permission and created another permission in the process.

I think that permissions should be registered somewhere in order to be used, and the declarative security machinery should barf (or at least complain loudly) at any attempt to protect something with an unregistered permission.

A simple solution that I've found to work decently is to have a 'permissions' module. The CMF does this (Products.CMFCore.CMFCorePermissions). It doesn't really register permissions, but it names them:: ModifyPortalContent = 'Modify Portal Content' Then code that needs to use that permission imports CMFCorePermissions: security.declareProtected(CMFCorePermissions.ModifyPortalContent, 'edit') def edit(self, ...): It's not a perfect solution, but it does work - and it gives a place of reference to discover what the Python name of a permission is. I think the Zope AccessControl package has a similar module now. Moving away from the 'string addiction' is a major effort. I don't know how easily it could be retrofitted into the Zope2 architecture, but I do think this should be a major concern for Zope 3 since the core architecture is going through its first significant overhaul in a very long time. Jeffrey P Shell, jeffrey@cuemedia.com