On 10/23/2000 11:37 AM, "Chris Withers" <chrisw@nipltd.com> wrote:
...yeah, Zopelet means absolutely nothing, and will just add to confusion :-(
The worse confusion is choosing a name that means something and then either o Having to explain that it means different things in different contexts, even within Zope. (This is a bigger problem with the name Method than the whole binding issue. Ditto for script. Instructing a user to write a Python Script will cause a Python programmer to go to the file system). o Having to explain "it's like ... but different..." This was apparently one of the other problems with the name Method, in that PythonMethods (the through-the-web variety) may or may not behave like traditional Methods in programming languages. This is especially bad when the code is Python since Python is also what we develop in. Python can now exist in many places in Zope (web, Extensions/, and Products (disk based)). External Methods were a nice name in that they connoted that it was a chunk of code that was external to Zope (at least the ZODB). The use of 'method' can come back into issue regarding how they got bound (ugh), but the External bit fit. If I was told "write an External method", I knew what that meant. When*ever* I hear someone mention writing a new python method to do something, it has to be qualified with "you mean in a product\class on the file system or a _PythonMethod_?" Function, Script.. They all fall prey to the same thing. Zopelets follows the cute naming of Applet, Servlet, Scriptlet... (IE has Scriptlets). I'm not advocating it entirely, but it follows a nice silly tradition in a way that is explainable - small chunks of Zope code managed through the web. And they happen to be in Python. (or could be predicated by the language of choice). Jeffrey P Shell, jeffrey@Digicool.com http://www.digicool.com/ | http://www.zope.org