On 10/23/2000 11:37 AM, "Chris Withers" <[EMAIL PROTECTED]> 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
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, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -