Re: [Zope] - Where do I put source code files???
From: katz@wam.umd.edu (Roey Katz)
I don't understand if example.cgi should be under the Principia object heirarchy or under the actual filesystem.
There's an echo in here - I asked this morning. In the filesystem. And then connect up external methods.
Wouldn't I have to 'import Globals; import Acquisition; ...' within the example's source code in order to access the Zope ORB?
I think they are already in the name space when your module is imported into it. You are going under the assumption that your module is the top level entity, it is not. They tell me they don't want to put python code in the object database. Just why should be put on the zope web site. Bruce -- The $70 Billion US "budget surplus" hardly offsets our $5 Trillion national debt. The debt increased by $133 Billion in the same year we found a "surplus". More debt is predicted for 1999. See www.concordcoalition.org . Bruce Perens K6BP bruce@pixar.com 510-620-3502 NCI-1001
At 03:29 PM 1/21/99 PST, Bruce Perens wrote:
From: katz@wam.umd.edu (Roey Katz)
I don't understand if example.cgi should be under the Principia object heirarchy or under the actual filesystem.
There's an echo in here - I asked this morning. In the filesystem. And then connect up external methods.
Wouldn't I have to 'import Globals; import Acquisition; ...' within the example's source code in order to access the Zope ORB?
I think they are already in the name space when your module is imported into it. You are going under the assumption that your module is the top level entity, it is not.
They tell me they don't want to put python code in the object database. Just why should be put on the zope web site.
Where to put your source files all depends on what you are trying to do. Let's take some example scenarios. Questions: 1. How do I publish my own Python modules with ZPublisher, but *without* the Zope management framework? 2. How do I publish my own Python methods and classes within the Zope Framework? Answers: (BTW, these two scenarios are detailed on http://www.zope.org/Documentation/Reference) 1. You can publish your own Python modules by setting up your web server to use ZPublisher to publish them. This can be done most easily with ZopeHTTPServer like so: ZopeHTTPServer.py myModule In this case, you can place your Python files anywhere you want. Just tell ZopeHTTPServer where to find them (ZopeHTTPServer.py /path/to/my/Module) or else cd to the directory where your module is located and run ZopeHTTPServer. Find out more about ZopeHTTPServer in its long doc string, or by running it without any arguments. There are other ways to do it, for example, using CGI or PCGI, etc. If you are serious about publishing your own modules you will probably be interesting in: * The ZPublisher Component release which is geared to people who want to publish their own modules. It contains the ZPublisher and other things you will need. http://www.zope.org/Download/ZPublisher * Tutorials on how to publish your own Python modules. These tutorials assume that your are not using the Zope management framework. http://www.zope.org/Documentation/Reference/ObjectPublishingIntro http://www.zope.org/Documentation/Reference/Trinkets 2. You can publish your own Python code with the Zope framework by fitting it to the framework. Your choices are: * External Methods * Product API These two methods of extending the Zope framework are detailed on the Zope site: External Methods Documentation http://www.zope.org/Documentation/Reference/ExternalMethods Product API Documentation http://www.zope.org/Documentation/Reference/API http://www.zope.org/Documentation/Reference/Tutorial In both cases you have some choice about where to locate your source files. See the documentation for more details but here's my quick rule of thumb: * Put general modules and packages in the Shared Package. Things in the Shared package are available to all of Zope. For example, I might want to put some general purpose xml module in /usr/local/Zope/lib/python/Shared/AmosL/xml-rpc.py. * If you are making an External Method, put your module in the Extensions directory. For example, you might want to define an External Method in /usr/local/Zope/Extensions/amosMethods.py * If you are making a Product your Product will be a Python package located in the lib/python/Products directory. For example you might locate your SuperDocument product in the /usr/local/Zope/lib/python/Product/SuperDocument directory. Make sense? This is how things stand right now. However, there is lively debate about other possibilities for extending Zope with your own Python Code. Right now there is *no* support for locating Python code in the object database. This has been debated before on the list (check egroups). The conservative forces believe it to be security issue. Others say it would be convenient to allow code in the object database and through-the-web editing of code. No one to my knowledge has put together a Product to allow such a beast. If anyone decides to go down this road, they should probably look into controlled execution or something... Right now there is only experimental support for publishing your own modules without the Zope management framework with the management framework. Yes, this is a bit of an oxymoron ;-) That experiment is called ExternalObjects, and is available on the Contrib page. http://www.zope.org/Download/Contrib It comes with some instructions in the doc strings. I hope this clears things up a little. -Amos
Amos, I've followed a few examples in the documentation, however, I run into problems right away and I suspect my configuration may be at fault.
1. You can publish your own Python modules by setting up your web server to use ZPublisher to publish them. This can be done most easily with ZopeHTTPServer like so:
ZopeHTTPServer.py myModule
# pwd /usr/local/Zope-1.9.0-src/ZopeHTTPServer # ./ZopeHTTPServer.py /home/.../Main.py Traceback (innermost last): File "./ZopeHTTPServer.py", line 529, in ? if __name__=="__main__": main() File "./ZopeHTTPServer.py", line 527, in main start(module_file,host,port,threading,env) File "./ZopeHTTPServer.py", line 467, in start set_published_module(module_file,BoboRequestHandler,env) File "./ZopeHTTPServer.py", line 460, in set_published_module import cgi_module_publisher ImportError: No module named cgi_module_publisher -- Switching to /usr/local/Zope-1.9.0-src/ and executing "./serve.sh &" (as root) works, however -- what am I doing wrong? and how do I specify a URL which I want the published module to be mapped to? example: ./ZopeHTTPServer.py -t -p 80 \ /home/.../MyModule/main.py --map_to /home/~katz in netscape: if I go to: http://www.mydomain.com/home/~katz/MyModule/main the ZopeHTTPServer responds with: MyModule.main() or, instead: if I go to: http://www.mydomain.com/home/~katz the ZopeHTTPServer responds with: MyModule.main() (assuming I've 'mapped' MyModule --> /home/~katz) would it be feasible if such a feature existed? once my object is published, which URL accesses it? Thank you, Roey
On Thu, 21 Jan 99 15:29 PST, you wrote:
From: katz@wam.umd.edu (Roey Katz)
I don't understand if example.cgi should be under the Principia object heirarchy or under the actual filesystem.
There's an echo in here - I asked this morning. In the filesystem. And then connect up external methods. If I want to connect external methods, then the Principia guide says there
I think they are already in the name space when your module is imported into it. You are going under the assumption that your module is the top level entity, it is not.
They tell me they don't want to put python code in the object database. Just why should be put on the zope web site.
So I should write my code as an external method for the time being? This confuses me; if I have an external method (and then add the external method to a directory through the Principia GUI), then when I need to package my Product, what becomes of all the configuration information for that directory? example: # assuming I already have a directory under # /usr/local/Zope<version>/lib/python/Products, and assuming that # I have properly set up __init__.py, I should then see a # Framework directory /Control_Panel/Products/testproduct # when I "cd /usr/local/Zope<version>; ./serve.sh &" # assuming this, I get: /Control_Panel/Products/testproduct # now I add objects through the Principia GUI: added External Method 'ext_meth1' added External Method 'ext_meth2' added Document 'index.html' (or 'index_html'?) added Image 'img_1' --- now: 1) how do I specify that /Control_Panel/Products/testproduct should be mapped to http://www.mydomain.com/ ? 2) Suppose I want to demonstrate Zope to someone and I must install it on their computer. Must I repeat what I did above, or is there some easy way of copying/tarballing a project in its entirety (framework + filesystem data together)? The problem I see is that important objects are kept within the Zope framework instead of the filesystem, which forces me to care about which object is in which storage heirarchy (Zope object framework or normal filesystem?) 3)
Bruce Perens wrote:
They tell me they don't want to put python code in the object database. Just why should be put on the zope web site.
This is a little hard to respond to, since "python code in the object database" could mean a lot of different things. The narrow notion of storing source code in the database is a little problematic, since it would make transport of database files *even more* of a security issue than it is now. The existing worry about the power of pickles is one of the reasons (other than time :) why we've avoided making things like export/import and "replication" more convenient. Knowing that Python source code might be transported in pickles would tend to make us (me?) even more paranoid. Of course, there's nothing preventing anyone from storing Python source in the database now, so offiecilly sanctioning it would not be much of a step. :) Now, presumably, people don't *just* want to store python code in the database. They also want to edit it through the web. Would such methods be subject to restrictions, like DTML is? I presume so. I'm not opposed to this, but someone would need to at least extensd the security machinery used for DTML expressions to full Python code. (Restricted execution is not enough IMO.) Note that one of the useful things about ExternalMethods is that they aren't subject to the security rules now. Then again, one might have a development environment that was more closed, and therefore secure for editing Python code that was stored in the database. Some people might want to store module and class definitions in the database or import from the database. This could be pretty cool, if done well. I'm not opposed to it in principle. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (4)
-
Amos Latteier -
bruce＠pixar.com -
Jim Fulton -
katz＠wam.umd.edu