RE: [Zope] - How do I publish this object?
Skip wrote:
My sentiments exactly. It would appear that Principia and Zope traded off Bobo's simple object publishing model for a very nice way to manage hierarchical web sites. The extra complexity added under the covers looks like it will make it very difficult to convert existing CGI-based sites to Zope. I have a site that uses 30-40 CGI scripts to do its business. At this stage, converting them looks like it will be fairly difficult. If I'm missing something, please fill me in. If not, is there some simpler way to publish objects through Zope other than the current Product API?
As mentioned by Amos, External Methods are a simple way to plug functions into the object system. You still, though, have to "add" the External Method to the folder you want to bind them to. Perhaps, though, there should be a slot for doing old-style Bobo programming. For instance, we could have a special top-level directory called "/Bobo". Anything modules placed in that directory can be old-style Bobo applications, whose functions are automatically bound to the top-level folder. Thus, creating a module /Bobo/Skip.py: ========================= """Simple Hello World""" def hello(self,name): """self is bound to top level folder""" return '<P>Hello, %s' % name ========================= Automatically makes the URL /hello?name=Skip functional. Perhaps the Control Panel could have a folder containing all imported modules that lets you reload them. OK some clever soul, give us some patches! --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909
At 06:56 PM 12/8/98 -0500, Paul wrote:
As mentioned by Amos, External Methods are a simple way to plug functions into the object system. You still, though, have to "add" the External Method to the folder you want to bind them to.
Perhaps, though, there should be a slot for doing old-style Bobo programming. For instance, we could have a special top-level directory called "/Bobo". Anything modules placed in that directory can be old-style Bobo applications, whose functions are automatically bound to the top-level folder.
Thus, creating a module /Bobo/Skip.py: ========================= """Simple Hello World"""
def hello(self,name): """self is bound to top level folder""" return '<P>Hello, %s' % name =========================
Automatically makes the URL /hello?name=Skip functional.
Perhaps the Control Panel could have a folder containing all imported modules that lets you reload them.
How about a Bobo Product that allows you to add a Bobo module from any place in the filesystem to anywhere in your Zope hierarchy. This is much more flexible and would provide you with a marker that your external code was in the Zope namespace. Call it "External Module" Very easy to write, I bet. If no one has written this by this week end, I'll do it! -Amos
Amos Latteier wrote:
At 06:56 PM 12/8/98 -0500, Paul wrote:
As mentioned by Amos, External Methods are a simple way to plug functions into the object system. You still, though, have to "add" the External Method to the folder you want to bind them to.
Perhaps, though, there should be a slot for doing old-style Bobo programming. For instance, we could have a special top-level directory called "/Bobo". Anything modules placed in that directory can be old-style Bobo applications, whose functions are automatically bound to the top-level folder.
Thus, creating a module /Bobo/Skip.py: ========================= """Simple Hello World"""
def hello(self,name): """self is bound to top level folder""" return '<P>Hello, %s' % name =========================
Automatically makes the URL /hello?name=Skip functional.
Perhaps the Control Panel could have a folder containing all imported modules that lets you reload them.
How about a Bobo Product that allows you to add a Bobo module from any place in the filesystem to anywhere in your Zope hierarchy. This is much more flexible and would provide you with a marker that your external code was in the Zope namespace. Call it "External Module"
This would be a huge security security hole. Perhaps a combination of your approach and Paul's would be appropriate. Drop-on "Bobo Module" objects that would put a published module at some place in a folder. The module would have to come from some designated directory, possibly even a package. I would not want these modules to ude BoboPOS however. And I fear that their interaction with the rest of the framework would be disappointing and would consume alot of support resources. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 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 (3)
-
Amos Latteier -
Jim Fulton -
Paul Everitt