Re: [Zope3-Users] Adapting or monkey patching?
Currently I have a adapter that subclasses OFS.SimpleItem.Item and re-implements the raise_standardErrorMessage method with my line of code that sends the event. I have know idea what OFS is, but what you're describing isn't an adapter at all. I would try writing a real adapter like: class OFSToCallable(object): implements(ICallalable) # ICallable is a stub interface adapts(OFS.interfaces.IItem) def __init__(self, ctx): self.ctx = ctx def __call__(self, *p, **kw): try: self.ctx(*p, **kw) except Exception, e: # handle the exception and dispatch event here pass I'm just a zope dilettante, so take my advice with a grain of salt. -- \/\/\\\ / // //\/\\\ \\\/ \\// /\ \/ \\/ /\/ / /\/ /\ \\\ \/ / /\/ /\ /\\\ \\ / /\\\ /\\\ \/\ \/\/\/\\ d.p.s ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Containers and ZODB
I'm new to zope3 and have been writing an application backed by a relational database. I wanted to created a IContainer implementation which essential provides a view of items in the database, but there is no need for to make the container instances manageable through the ZMI or persistent in either ZODB or through the ORM layer (incidentally, I'm using Storm). To paraphase how the application works, I have something like: class FooBarContainer(MyContainerImplementation): containedQuery = select * from foobars The implementation is slightly more complex, but really doesn't matter. I just want the container to exist at runtime, without any knowledge of it in ZODB. Nor do I want someone to have to explicitly add containers through the ZMI, since the containers I'm defining are inherently part of the application. Does anyone have any suggestions on a good way to achieve this? -- d.p.s ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Containers and ZODB
You don't really need to implement a container, you could just write a non persistent object (not derived from Persistent), and create a view on it. But the next problem is to be able to traverse to this object, since traversal starts from the root of the zodb. I thought a Container was a nice way of modeling the traversal aspect. For example, I want view that represents a list of foobars, or a list of foobars marked as `ready' etc. But again, I'm new to zope3, so there may be a better way of doing this that I haven't realized. Thanks for the suggestions. -- d.p.s ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
