acquisition-based class initialization on Zope startup
Here's an interesting hole I dug for myself; any ideas on how to get out? The question comes down to: is there any (reasonable) way to invoke a Zope Python Script automatically every time the server starts up. I realize this is a little weird, since Python scripts, DTML methods, and the like are for creating client-side pages, but I've found it convenient to also use them for site setup, editing meta-information such as properties for classes, etc. Is there perhaps something like a product's __init__.py that gets invoked late enough to be able to do Zope.app().unrestrictedTraverse, or perhaps another way to get at the Zope scripts and methods? Here's what I did that makes me want a solution to this challenge. I have some classes defined in my product. Initialization of these classes includes setting up some properties. Originally, the properties were defined in a file, and my product's __init__.py called a function that read the contents of the file and did Zope API stuff to setup the properties. Then I decided that the properties should be web-editable, not in a file in the product implementation, so I moved the file contents into Zope DTML methods (by the way, what *is* the preferred Zope type of straight text?), and I wrote a Python Script that initialized the properties for the classes based on the Zope methods. This way, a site manager can edit the properties, execute that Python script, and immediately have all instances of the class see the changes. I discovered to my chagrin that when I restart Zope, all the class properties have disappeared (of course), and my __init__.py no longer recreates them. So I have to add back in to __init__.py a call to something to recreate the properties, but that something has to either call the Zope Python script or get the contents of the DTML methods that define the properties, and during product loadup it's too early to try to navigate the Zope object hierarchy (which I normally do via Zope.app().unrestrictedTraverse, which I can give a path to my Zope Python script, and follow it with () to invoke it, which works in the debugger after Zope has started, but not while my product is being loaded; in fact, Zope doesn't even have an 'app' yet at that point).
Stick a call at the end of z2.py after Zope has loaded. Cheers. -- Andy McKay. ----- Original Message ----- From: "Mitchell Model" <mlm@acm.org> To: <zope@zope.org> Sent: Wednesday, October 31, 2001 4:18 PM Subject: [Zope] acquisition-based class initialization on Zope startup
Here's an interesting hole I dug for myself; any ideas on how to get out? The question comes down to: is there any (reasonable) way to invoke a Zope Python Script automatically every time the server starts up. I realize this is a little weird, since Python scripts, DTML methods, and the like are for creating client-side pages, but I've found it convenient to also use them for site setup, editing meta-information such as properties for classes, etc. Is there perhaps something like a product's __init__.py that gets invoked late enough to be able to do Zope.app().unrestrictedTraverse, or perhaps another way to get at the Zope scripts and methods?
Here's what I did that makes me want a solution to this challenge. I have some classes defined in my product. Initialization of these classes includes setting up some properties. Originally, the properties were defined in a file, and my product's __init__.py called a function that read the contents of the file and did Zope API stuff to setup the properties.
Then I decided that the properties should be web-editable, not in a file in the product implementation, so I moved the file contents into Zope DTML methods (by the way, what *is* the preferred Zope type of straight text?), and I wrote a Python Script that initialized the properties for the classes based on the Zope methods. This way, a site manager can edit the properties, execute that Python script, and immediately have all instances of the class see the changes.
I discovered to my chagrin that when I restart Zope, all the class properties have disappeared (of course), and my __init__.py no longer recreates them. So I have to add back in to __init__.py a call to something to recreate the properties, but that something has to either call the Zope Python script or get the contents of the DTML methods that define the properties, and during product loadup it's too early to try to navigate the Zope object hierarchy (which I normally do via Zope.app().unrestrictedTraverse, which I can give a path to my Zope Python script, and follow it with () to invoke it, which works in the debugger after Zope has started, but not while my product is being loaded; in fact, Zope doesn't even have an 'app' yet at that point).
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[original question asked, accompanied by a long story, how to perform acquisition-based actions when Zope starts up, in my case to initialize properties in my product classes based on Zope Python Scripts and data in DTML methods]
Stick a call at the end of z2.py after Zope has loaded.
Excellent! Radical!! Obvious!!! Wonder if I would have ever thought of that, and if I had, whether I would have thought it too crude.... Come to think of it, maybe z2.py should import an initially empty init.p (or site-init.py or zope-init.py or startup.py or whatever, in the root Zope directory where z2.py lives) to establish a clear hook for startup actions. Yes, people can edit z2.py, but do they realize that? Do they even realize z2.py exists? Do they assume z2.py is full of black magic and they shouldn't touch it? Do they realize that z2.py *is* the startup script? And you don't want to have to re-edit z2.py with every new release -- much easier just to copy over your initialization file for the new release; actually, that suggests that the init file should *not* be in the Zope root, but rather in INSTANCE_HOME (if using that scheme) so that you wouldn't have to do anything to move to a new version of Zope. [This isn't really big enough for a fishbowl propsoal is it? It would be great if someone from ZC would just say "Done."....]
[This isn't really big
enough for a fishbowl propsoal is it? It would be great if someone from ZC would just say "Done."....]
Well, I agree, that'd be nice.. I'd like to see something like this too. But we're a careful bunch. We'd like to understand the problem better and hear about proposed solutions -- our mechanism for that is the fishbowl. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
participants (4)
-
Andy McKay -
Chris McDonough -
Mitchell L Model -
Mitchell Model