Michael Lausch wrote:

On Sat, 2002-03-30 at 00:06, Casey Duncan wrote:

...

Assuming these objects are mutable you might be able to do something like this at the end of your external method:

object.__allow_access_to_unprotected_subobjects__ = 1 return object

minutes before reading your reply i just found this out for myself, by looking throug the code of the ZSQL methods. Isn't this a hack? will this method also work with future releases of zope? or will zope 3 come up with a better method of integrating external python programs with zope?

This is a hack. It makes me feel cheap whenever I use it 8^). This is the "quick and dirty" way to get access. Its also a great way to open security holes too 8^).

to be honest i feel a little disapointed that there is not better documented way of doing this sort of stuff, since it semms to me that there is a huge potential in this. write your "business logic" in a python package and interface it with zope or use it as the model together with a glade generated GTK GUI.

The better way is to create a wrapper class and use declarative security on it to allow access to only those methods and subobjects that you really need TTW access to. That is not usually a five minute solution though. See the zope dev guide for details on this.

Will components be of any help? i can imagine to implement the interface class as a zope integrated class and use any other class as the implementation.

Well first off, Interfaces aren't classes regardless of whether you use a "class" declaration to create them or not. Hopefully future Python versions will allow us to define interfaces without using the confusing "class" statement. Declarative security will still be the way it works in Zope 3, however those declarations can be made in configuration files rather than code. That allows you to use modules and secure them properly in Zope without modifying code or creating wrapper classes. -Casey