Maybe the Zope-Dev guys have comments on this....
From: Jim Fulton <jim@digicool.com>
Michel,
You have advocated that methods should always be bound to the objects they are accessed in. You argue that there should be no choice in the matter.
I have to disagree strongly. I'll try to explain why.
In Python, methods are bound to instances. Methods are part of an instance's core behavior. They are specific to the kind of thing the instance is. In my words, methods are part of the genetic makeup of an object.
In Zope, we allow some methods to be bound to their context. This is done in a number of ways and is sometimes very useful. We have methods, like standard_html_header, which are designed to be used in different contexts.
We have other methods, like manage_edit that are designed to work on specific instances. It would be an egregious error if this method was acquired and applied to it's context.
We have some methods that are designed to bound to an instance (container, in your terminology) but that, because they are written in DTML, can be bound to other objects. This can cause significant problems. For example, methods defined in ZClasses almost always want to be bound to ZClass instances, not to other arbitrary objects.
<aside>There's a bonus problem with DTML Methods. When a DTML Method is invoked from another DTML Method, it is bound to neither the object it was accessed in or to the object it came from. It is bound to the calling namespace. It turns out that this is a useful behavior if the DTML Method is designed to be used as a "subtemplate". </aside>
There is no one "right" way to bind a method. There are good reasons to sometimes bind a method to it's context and sometimes bind a method to it's container (ie instance). There are even sometimes reasons to bind a method to a calling namespace.
The principle of least surprise doesn't help here, because methods defined in Python classes don't behave the way methods defined through the web do currently.
We *need* control over binding, as well as reasonable defaults.
If we can agree that we need binding control, the question arises as to some details and default names.
Should it be possible to do more than one binding at a time, using multiple names? If not, then I'd agree that the name 'self' should be used for either the context or container binding. If both bindings are allowed at the same time, then 'self' should refer to container binding to be consistent with standard Python usage and some name like 'context' should be used (by default) for contextual binding.
Jim
From: Michel Pelletier <michel@digicool.com>
Jim Fulton wrote:
Michel,
You have advocated that methods should always be bound to the objects they are accessed in. You argue that there should be no choice in the matter.
I advocate more points than that, like being able to document python with python, no XML mixed in with a language, Py Meths working like other methods do, but yes that is one of them.
My argument should be more flexible in regard to choice, a willing compromize is to switch the default binding of context and container, making 'self' the default for context and something else the default for container.
I have to disagree strongly. I'll try to explain why.
In Python, methods are bound to instances. Methods are part of an instance's core behavior. They are specific to the kind of thing the instance is. In my words, methods are part of the genetic makeup of an object.
Python methods are meant for through the web usability and programming ala the existing Zope model. 90% of your audience just scratched their heads.
In Zope, we allow some methods to be bound to their context. This is done in a number of ways and is sometimes very useful. We have methods, like standard_html_header, which are designed to be used in different contexts.
this is how I feel python methods should be designed to be used.
We have other methods, like manage_edit that are designed to work on specific instances. It would be an egregious error if this method was acquired and applied to it's context.
I think this is a weak argument, none of the built in Zope methods mean anything to the average user, they can't find them, click on them, edit them, or copy them to their own method to change and experiment with.
We have some methods that are designed to bound to an instance (container, in your terminology)
Python Method terminology
but that, because they are written in DTML, can be bound to other objects. This can cause significant problems. For example, methods defined in ZClasses almost always want to be bound to ZClass instances, not to other arbitrary objects.
<aside>There's a bonus problem with DTML Methods. When a DTML Method is invoked from another DTML Method, it is bound to neither the object it was accessed in or to the object it came from. It is bound to the calling namespace. It turns out that this is a useful behavior if the DTML Method is designed to be used as a "subtemplate". </aside>
This is because DTML binding is implicit, not because it's backward. This problem doesn't effect python methods because you allways bind a method in python when you call it. The question is how the initial method gets bound.
There is no one "right" way to bind a method. There are good reasons to sometimes bind a method to it's context and sometimes bind a method to it's container (ie instance). There are even sometimes reasons to bind a method to a calling namespace.
The principle of least surprise doesn't help here, because methods defined in Python classes don't behave the way methods defined through the web do currently.
We *need* control over binding, as well as reasonable defaults.
If we can agree that we need binding control, the question arises as to some details and default names.
I agree there must be control over binding, although your arguments above have not convinced me that Python Methods are doing it the right way, actually, it's convinced more than my argument, compromisingly of course, is more right.
Should it be possible to do more than one binding at a time, using multiple names? If not, then I'd agree that the name 'self' should be used for either the context or container binding.
I'm with you so far with that.
If both bindings are allowed at the same time, then 'self' should refer to container binding to be consistent with standard Python usage and some name like 'context' should be used (by default) for contextual binding.
That's what I disagree with. I don't think you've given a strong corollary to standard python usage. The only strong argument you've given so far is the ZClass one, but 10 gives you 1 that's not the primary use case (it may be the one in Fburg). People are going to be defining these methods in Zope to make their lives easier, probably bad design and mad hacks and no structure, but that's how 90% of the world gets their work done and easing that burden is the usability task. You have not convinced me that:
1. Something called a Python Method should not resemble a method definition in python.
2. Something called a Method in Zope should not behave like the other Methods (meaning through the web objects) in Zope
3. Common, *documented* well understood URL manipulations (context) are less important than (the less common) containment oriented design and ZClasses.
Consider the following passage in the documentation:
For example suppose you want to call a method named *viewFolder* on one of your folders. Perhaps you have many different *viewFolder* methods in different locations. Zope figures out which one you want by first looking in the folder that you are calling the method on. If it can't find the method there it goes up one level and looks in the folder's containing folder. If the method can't be found there it goes up another level. This process continues until Zope finds the method or gets to the root folder. If Zope can't find the method in the root it gives up and raises and exception.
and:
Zope breaks the parts of the path up and walks along the object hierarchy looking for each part. This process is called *URL traversal*. For example, when you give Zope the URL *Zoo/LargeAnimals/hippo/feed'*. It starts at the root folder and looks for an object named *Zoo*. It then moves to the *Zoo* folder and looks for an object named *LargeAnimals*. It moves to the *LargeObjects* folder and looks for an object named *hippo*. It moves to the *hippo* object and looks for an object named *feed*. The *feed* method is found in the *Zoo* folder by a process called *acquisition*. Now Zope has reached the end of the URL. It calls the last object found, *feed*, on the second to last object found, the *hippo* object. This is how the *feed* method is bound to the *hippo* object.
And further on:
Suppose 'feedHippo.py' is a Python Method. How could you call the 'Diet/feed' method on the 'LargAnimals/Hippo' object from your Python Method. Here's how::
self.Zoo.Diet.LargeAnimals.hippo.feed()
In other words you simply access the object using the same acquisition path as you would use if calling it from the web. Likewise in Perl you could say::
$self.Zoo.Diet.LargAnimals.hippo->feed();
Using methods from other methods is very similar to calling methods from the web. The semantics differ slightly but the same acquisition rules apply.
These paragraphs are just exceperts from two whole sections that try to, quite sucessfully acording to the feedback we've gotten, explain the method binding pattern in Zope. We give a real world application and justification in both sections on why this is useful and explain the concept in simple terms. Now, this needs to be re-explained, rewritten, and made overly complicated for what I feels are not very important reasons. Where are the applications and design patterns documented for your argument? Perhaps those could convince me if they justified it from the perspective of the beginner. I suggest you read over Chapter 7 and weigh these descision from the eyes of a newbie.
-Michel
This one is probably the most useful of the lot ;-)
From: Michel Pelletier <michel@digicool.com>
Greetings,
Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an interesting change. The world 'Method' is too overlaoded, as it means too much to too many people. Also, Python Methods don't work like methods in python, which was my argument, but they are very useful and there are sound reasons for them working like they do (which J, E and B convinced me of yesterdat). We have decided to change the name of Python Methods to something else, the current candidate being 'Python Script'.
'Script' objects make a lot of sense, they don't overload the concept of methods, they describe an action that people commonly want to do (script the web) and they clear up a lot of potential confusion for newbie and old-hat alike.
The bonus for all of this is that the only thing that needs to change is the name. Which name is still an issue though, and we want your input. what do you think of the idea of Perl Script objects?
The other issue, for the sake of documentation, is variable binding (which was the root of our disagreement yest. Python Methods do not bind variables and argument like methods in python do). From what I can see, Perl Methods seem to get 'self' pass in as a first argument. Is this all there is too it or are there more details? Python Methods have five special variables (defined on the bindings tab) that get created in the namespace of the method. Should perl methods work the same way and not have special variables passed in as arguments? This would probably be more consistent with the Python model, and since 'self' will probably not be the name of the variable bound to either the container or the context it should be more explicit for perl methods also.
What do you think?
-Michel
From: Michel Pelletier <michel@digicool.com>
Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an interesting change. The world 'Method' is too overlaoded, as it means too much to too many people. Also, Python Methods don't work like methods in python, which was my argument, but they are very useful and there are sound reasons for them working like they do (which J, E and B convinced me of yesterdat). We have decided to change the name of Python Methods to something else, the current candidate being 'Python Script'.
Well, I think script ain't right. How about 'Function', since, to me, the things you've described sound exactly like normal Python Functions. A function is callable but has no logic about a magic 'self' argument or anything else, for that matter.
methods, they describe an action that people commonly want to do (script the web) and they clear up a lot of potential confusion for newbie and old-hat alike.
'script' implies a sequential execution of a lump of code that doesn't 'return' anything. That doesn't sound like the old Python Methods. They get arguments (from the namespace, some of which is introduced by the bindings tab) and return something, probably text, that results from their execution and, I guess, their return statement. Just to overstate the point (;-), that sounds like a function to me...
Python Methods have five special variables (defined on the bindings tab) that get created in the namespace of the method. Should perl methods work the same way and not have special variables passed in as arguments?
Sounds like they should have a binding tab and no 'special' self argument. Maybe they should both subclass a generic 'Function' object which provides the interface for this? Then other languages might get implemented later down the line ;-) cheers, Chris
On Fri, Oct 20, 2000 at 01:01:59PM +0100, Chris Withers wrote:
This one is probably the most useful of the lot ;-)
From: Michel Pelletier <michel@digicool.com>
Greetings,
Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an interesting change. The world 'Method' is too overlaoded, as it means too much to too many people. Also, Python Methods don't work like methods in python, which was my argument, but they are very useful and there are sound reasons for them working like they do (which J, E and B convinced me of yesterdat). We have decided to change the name of Python Methods to something else, the current candidate being 'Python Script'.
'Script' objects make a lot of sense, they don't overload the concept of methods, they describe an action that people commonly want to do (script the web) and they clear up a lot of potential confusion for newbie and old-hat alike.
Oh, yuck! Now we have to explain why PythonScript is safe, and JavaScript sucks rocks (from a security standpoint). And from common web convention, it would appear that PythonScript would run on the client side, rather than the server side. Since the -let suffix appears to have taken on a server side connotation, perhaps that can be used. Python Function is not quite right, as it is fairly common (for me, at least) to define some helper functions in a Python Method. But it is better than Python Script. So, I guess my preferences would be: PythonSafeScriptlet PythonScriptlet PythonSafeScript PythonSafeFunction PythonFunction PythonBundle PythonMethod PythonScript in descending order of preference.
-Michel
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On 10/20/2000 12:02 PM, "jpenny@universal-fasteners.com" wrote:
Oh, yuck! Now we have to explain why PythonScript is safe, and JavaScript sucks rocks (from a security standpoint). And from common web convention, it would appear that PythonScript would run on the client side, rather than the server side. Since the -let suffix appears to have taken on a server side connotation, perhaps that can be used.
Python Function is not quite right, as it is fairly common (for me, at least) to define some helper functions in a Python Method. But it is better than Python Script.
So, I guess my preferences would be:
PythonSafeScriptlet PythonScriptlet PythonSafeScript PythonSafeFunction PythonFunction PythonBundle PythonMethod PythonScript
in descending order of preference.
My prefs are. Python Op(s). Which can be short for Python Operation(s) or Python Operative(s) (like agent). ThroughTheWeb ops can then be Python Safe Ops and those secretive unsecured External Methods could be Python Black Ops. All kidding aside, Op gets my nod for a name. (and PerlOp sounds close enough to Plop to remind us all of Beavis and Butthead.) I think Function and Script suffer from a similar problem that Method does -- depending on the context, they mean different things. The phrase "Why don't you just write a Python script to do that?" or "...Python function" could mean in either case adding an object to Zope, or writing some Python on the file system that may or may not have anything to do with Zope. If we want to use Script or Method or Function, we need to drop Python from the title and rename that side of the name (from ZPython to ZopePython... but I'm not terribly fond of either of those). The problem here is that we'd have to do a similar thing for Perl. Bundles sound like Jars in Java - like you're getting\using a collection of services bundled together, but can potentially be individually extracted. Jeffrey P Shell, jeffrey@Digicool.com http://www.digicool.com/ | http://www.zope.org
jpenny@universal-fasteners.com wrote:
'Script' objects make a lot of sense, they don't overload the concept of methods, they describe an action that people commonly want to do (script the web) and they clear up a lot of potential confusion for newbie and old-hat alike.
Oh, yuck! Now we have to explain why PythonScript is safe, and JavaScript sucks rocks (from a security standpoint).
The proposal is not for PythonScript but a "Python Script". We are not inventing a new language, this is python, we are just coming up with the name for an object. Don't capitalize it and you'll see what I mean. Go write a python script. I'm gonna write a python script that handles this HTML form. If we do this with a python script instead of a DTML method, it will be much clearer. Wow, this perl script has lots of slashes in it.
And from common web convention, it would appear that PythonScript would run on the client side, rather than the server side. Since the -let suffix appears to have taken on a server side connotation, perhaps that can be used.
Hmm. Yes I agree the -let suffix may have a sttronger server side flavor, but I disagree that the word script has any strong connection to the client only.
Python Function is not quite right, as it is fairly common (for me, at least) to define some helper functions in a Python Method. But it is better than Python Script.
Function is just as technical as method. These are OO techncial programming terms (function less than method). The idea is to lower the bar for people using Zope. People who only know HTML will be much more likely to grok what a script is than a method. We want to avoid elitism. Method is total OO elitism, function less so because it's very language neutral, and script is like plain vanilla ice cream, everyone gets it. Like chocolate and coconut-shaving covered almonds, technical details mixed in with your ice-cream will appeal only to a smaller crowd. It will not help define what 'ice cream' is. It will turn away a group of users who may have never know they could mix in sardines and sweet tarts. Technical details before the key idea is explained is *dangerous* belive me, and it is the pitfall of all existing Zope documentation to date. The new DC documentation motto is "Explain key ideas in simple terms." Method is not a simple term.
So, I guess my preferences would be:
PythonSafeScriptlet PythonScriptlet PythonSafeScript PythonSafeFunction PythonFunction PythonBundle PythonMethod PythonScript
in descending order of preference.
I'll add these to the list of candidates. Thanks! -Michel
On Fri, Oct 20, 2000 at 02:18:47PM -0700, Michel Pelletier wrote:
jpenny@universal-fasteners.com wrote:
The proposal is not for PythonScript but a "Python Script". We are not inventing a new language, this is python, we are just coming up with the name for an object. Don't capitalize it and you'll see what I mean. Go write a python script. I'm gonna write a python script that handles this HTML form. If we do this with a python script instead of a DTML method, it will be much clearer. Wow, this perl script has lots of slashes in it.
I understand, but if naming is under consideration, I worry about inadvertant connotations. I feel that in the web space, _-script has come to mean that the language is a client side actor, witness javascript, ecmascript, vbscript. (On the other hand, PythonScript, PerlScript, and ReXXScript appear be server side stuff in ASP.) And I see a difference between PythonScript and Python Script, but I don't hear it!
Function is just as technical as method. These are OO techncial programming terms (function less than method). The idea is to lower the bar for people using Zope. People who only know HTML will be much more likely to grok what a script is than a method. We want to avoid elitism. Method is total OO elitism, function less so because it's very language neutral, and script is like plain vanilla ice cream, everyone gets it.
Like chocolate and coconut-shaving covered almonds, technical details mixed in with your ice-cream will appeal only to a smaller crowd. It will not help define what 'ice cream' is. It will turn away a group of users who may have never know they could mix in sardines and sweet tarts. Technical details before the key idea is explained is *dangerous* belive me, and it is the pitfall of all existing Zope documentation to date.
Actually, I am not sure that script is much less technical than function. I think script, as in bash script, or scripting language is very crabbed and technical indeed. The only pre-computer usages I know of script(n.) are indicative of a cursive style of writing, apeper money, or a thing that playwrights produce. I don't think that playwrights are going to suddenly start wanting to use python! I think that script, as in "scripting language" is simply something that most people indeed do not get!
The new DC documentation motto is "Explain key ideas in simple terms." Method is not a simple term.
I don't disagree with your goal. I do disagree with this particular choice of words. I can see four potential properties that one could want to emphasize about a python method. 1) It is safer (to the Zope server) than a python external method. 2) It safer to the end user than a JavaScript (it never touches the client). 3) It uses python, and not something else as its implementation technique. 4) In OO terms, it is not really a Method. Hence the preference for Safe in the name. Even a newbie ought not to be able to cut himself too badly on a python method. There is talk of perl methods. So we need python in the description. Now we just need a generic term, which will not cause other confusions later on down the road for the concept. I really don't like script, especially next to a language name (in the web domain). You don't like function (which was not my suggestion). Thingie seems a bit too non- descriptive. Widget has technical meaning. Perhaps task or job are suitable, as in Safe Python Task Safe Python Job Safe Python Subtask Safe Python Function Safe Python Script Then external methods, which are often also not methods, can become Flexible Python Task Flexible Python Job Flexible Python Subtask Flexible Python Function Flexible Python Script But if you really want to use Tame Snake Thingy, and Wild Snake Thingy, go ahead, but please do not credit me in the documentation! As another obesrvation, substituting script for method is not really all that helpful for the other (misnamed) method, DTML Method. DTML Script is just not all that much clearer!
Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
jpenny@universal-fasteners.com wrote:
<snip good discussion>
Now we just need a generic term, which will not cause other confusions later on down the road for the concept. I really don't like script, especially next to a language name (in the web domain). You don't like function (which was not my suggestion). Thingie seems a bit too non- descriptive. Widget has technical meaning. Perhaps task or job are suitable, as in Safe Python Task Safe Python Job Safe Python Subtask Safe Python Function Safe Python Script
Then external methods, which are often also not methods, can become Flexible Python Task Flexible Python Job Flexible Python Subtask Flexible Python Function Flexible Python Script
But if you really want to use Tame Snake Thingy, and Wild Snake Thingy, go ahead, but please do not credit me in the documentation!
Well they'll all go on the list of candidates! Thanks for your input, I kinda like task...
As another obesrvation, substituting script for method is not really all that helpful for the other (misnamed) method, DTML Method. DTML Script is just not all that much clearer!
Rumor has it DTML Methods are going to be renamed to "DTML Template" or something like that. Keep in mind also that we are moving towards a new architecture with "Documents" and "Templates" (ala HyperDOM). I think Scripts fits right in there: Documents, Templates and Scripts or Documents, Templates and Methods ? -Michel
Michel Pelletier wrote:
<snip good discussion>
<and move on to something REALLY silly! :^>
jpenny@universal-fasteners.com wrote:
descriptive. Widget has technical meaning. Perhaps task or job are suitable, as in Safe Python Task Safe Python Job Safe Python Subtask Safe Python Function Safe Python Script
Then external methods, which are often also not methods, can become Flexible Python Task Flexible Python Job Flexible Python Subtask Flexible Python Function Flexible Python Script
But if you really want to use Tame Snake Thingy, and Wild Snake Thingy, go ahead, but please do not credit me in the documentation!
Documents, Templates and Scripts or Documents, Templates and Methods
I REALLY like Thingy! And a very Pythonesque choice it would be ... :^) Python Thingies and Perl Thingies. How nice to be so connotationless! ... but maybe not so connotationless ... recalling the usage of "thingy" in the Python, Monty oeuvre ("YOU know ... THINGY!!") ... you might want to consider Tame Snake Sex, and Wild Snake Sex, so then you have Documents, Templates, and Sex Python Sex vs. Perl Sex? ... wow, just think of it! Of course, alibis about working late would have to be carefully worded ... Sorry ... it's late on a Friday ... but I DO like Thingy! :^) Cheers, -- Steve. oo _\o \/\ \ / ____________________________________________ oo _________________ "Sometime you're the windshield; sometime you're the bug." - Knopfler Stephen C. Waterbury Component Technologies Code 562, NASA/GSFC and Radiation Effects Branch Greenbelt, MD 20771 Engineering Web/Database Specialist Tel: 301-286-7557 FAX: 301-286-1695 WWW: http://misspiggy.gsfc.nasa.gov/people/waterbug.html _________________________________________________________________
Michel Pelletier wrote:
Keep in mind also that we are moving towards a new architecture with "Documents" and "Templates" (ala HyperDOM). I think Scripts fits right in there:
Documents, Templates and Scripts
or
Documents, Templates and Methods
I tend to think of things as: Objects, Views (or Templates) and Blocks. The diference (for me) between a View and a Block is whether they are intended to be accessed directly by a client (browser). Blocks also tend to be reuseable in many views (I typically have a Block (DTML Method) called main_navigation, for example), and can be composed of other Blocks. Views like index_html may be reused, but usually through acquisition, not recomposition. The lines are fuzzy though, since I'm usually using the same types of objects (DTML Methods) for both Views and Blocks. Perhaps we need an object type that is not directly accessible from a client (but may only be called or rendered from other objects) in order to clarify the distinction. Michael Bernstein.
Michael Bernstein wrote:
The diference (for me) between a View and a Block is whether they are intended to be accessed directly by a client (browser). Blocks also tend to be reuseable in many views (I typically have a Block (DTML Method) called main_navigation, for example), and can be composed of other Blocks. Views like index_html may be reused, but usually through acquisition, not recomposition.
I like the idea behind blocks, I think it's probably the best name yet and described how most people use things like PythonMethods, external method and DTML Methods :-) cheers, Chris
jpenny@universal-fasteners.com wrote:
I can see four potential properties that one could want to emphasize about a python method.
1) It is safer (to the Zope server) than a python external method. 2) It safer to the end user than a JavaScript (it never touches the client). 3) It uses python, and not something else as its implementation technique. 4) In OO terms, it is not really a Method.
Good points :-)
Hence the preference for Safe in the name. Even a newbie ought not to be able to cut himself too badly on a python method.
I dunno...
descriptive. Widget has technical meaning. Perhaps task or job are suitable, as in Safe Python Task Safe Python Job
Nah, they have too many cron-esque associations. Sounds like things to be found on a to-do list on in a schedule of some sort.
Safe Python Subtask
:-(
Then external methods, which are often also not methods, can become Flexible Python Task
Well, felxible doesn't really explain a lot. Filesystem is probably the most explicit. I dunno, I actually like Jeff's suggestion of Operation giving you: PythonMethod -> Python Operation External Method -> Filesystem Python Operation The same could also apply to DTML and Perl Methods. A nice side effect is that you could have Filesystem DTML Operation replace those horribly named HTML File objects you get when use grab your DTML out of .dtml files on disk. Especially as they bypass all known security ;-) cheers, Chris
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. Ken klm@digicool.com
Ken Manheimer wrote:
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful:
Python Zopelet Perl Zopelet XSLT Zopelet
Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general.
This is the first one with which i'm comfortable - but i may well have missed something.
...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( Chris . o O ( what the hell is a Zopelet? ;-)
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
Chris Withers wrote:
Ken Manheimer wrote:
Python Zopelet Perl Zopelet XSLT Zopelet
Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general.
... Zopelet means absolutely nothing, and will just add to confusion :-(
I agree with Ken: I think it's a good choice because it *is* Zope-specific -- I think Zope should be in the name. If you are using Zope, it will be meaningful; if not, it won't -- and shouldn't be. I also think "Zopelet" does not "mean absolutely nothing" in terms of connotation -- it carries the connotations that Ken mentioned, which is good. My $0.02. -- Steve. oo _\o \/\ \ / ____________________________________________ oo _________________ "Sometime you're the windshield; sometime you're the bug." - Knopfler Stephen C. Waterbury Component Technologies Code 562, NASA/GSFC and Radiation Effects Branch Greenbelt, MD 20771 Engineering Web/Database Specialist Tel: 301-286-7557 FAX: 301-286-1695 WWW: http://misspiggy.gsfc.nasa.gov/people/waterbug.html _________________________________________________________________
Chris Withers wrote:
Ken Manheimer wrote:
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful:
Python Zopelet Perl Zopelet XSLT Zopelet
Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general.
This is the first one with which i'm comfortable - but i may well have missed something.
...yeah, Zopelet means absolutely nothing, and will just add to confusion :-(
Chris . o O ( what the hell is a Zopelet? ;-)
I have to say that I don't like Zopelet either. I guess nobody else likes my 'Blocks' nomenclature: Python Blocks Perl Blocks DTML Blocks As I mentioned before, I tend to use DTML Methods in two contexts: - as Views on objects (Templates) - as building blocks for Views In one context (Views/Templates), the DTML method is meant to be accessed directly through the web. In the other context (Block), the DTML method is only ever accessed by a View. I would actually like to have a Block object that is not directly accessible, without having to go through some proxy-role rigamarole. Something else to consider for these two Use Cases of DTML/Python/Perl Methods/Blocks/Scripts, is that typically only the Block Use-Case is expected to be re-used through recomposition, as well as acquisition, while Templates/Views are usually re-used through Acquisition only. I'm not sure this has any impact on the 'Method Binding' argument floating around, but I thought I'd mention it again in that context. HTH, Michael Bernstein.
Some name suggestions - block has been suggested before What about - ZopeCodeBlock from there: Internal Python ZopeCodeBlock External Python ZopeCodeBlock Internal Perl ZopeCodeBlock Safe Python ZopeCodeBlock Alternatively something like ZopeBrainBlock might be considered, though I do not particularly like it my 2 cents Rik
Michel Pelletier wrote:
Python Function is not quite right, as it is fairly common (for me, at least) to define some helper functions in a Python Method. But it is better than Python Script.
That's a good point I hadn't thought of :-S
Function is just as technical as method. These are OO techncial programming terms (function less than method). The idea is to lower the bar for people using Zope. People who only know HTML will be much more likely to grok what a script is than a method. We want to avoid elitism. Method is total OO elitism, function less so because it's very language neutral, and script is like plain vanilla ice cream, everyone gets it.
No offence, but I don't think any of the above paragraph holds any weight. People who only know HTML won't be writing Python(Method/Function/etc)s anyway. I don't think any out of 'script', 'method' or 'function' will have more meaning than any of the others to these people. These are just words we're talking about, to the non-technical, it's not actually going to matter what they are. The main point is to avoid confusion, especially where words have associated meaning for technical people. That, IIUC, is why this discussion started in the first place...
Like chocolate and coconut-shaving covered almonds, technical details mixed in with your ice-cream will appeal only to a smaller crowd.
Vanilla Ice cream gets boring quickly! This ain't a good metaphor for your argument ;-)
The new DC documentation motto is "Explain key ideas in simple terms." Method is not a simple term.
Can you please make sure this doesn't become 'use less meaningful/incorrect vocabulary in an attempt to keep it simple, and so ending up with even more confusing terminology' ;-) cheers, Chris
On Fri, 20 Oct 2000 12:54:19 +0100, Chris Withers <chrisw@nipltd.com> wrote:
Consider the following passage in the documentation:
Noooooo - Context-based instance-space applications are a major source of pain, bugs and security holes. They might be the one thing that Zope does different (and therefore they need to be explained) but that doesnt make them right.
Suppose 'feedHippo.py' is a Python Method. How could you call the 'Diet/feed' method on the 'LargAnimals/Hippo' object from your Python Method. Here's how::
self.Zoo.Diet.LargeAnimals.hippo.feed()
In other words you simply access the object using the same acquisition path as you would use if calling it from the web. Likewise in Perl you could say::
$self.Zoo.Diet.LargAnimals.hippo->feed();
Using methods from other methods is very similar to calling methods from the web. The semantics differ slightly but the same acquisition rules apply.
Thats fine until: * someone adds an property named feed to an object at an intermediate location in the containment heirarchy. This breaks the cron job that calls self.Zoo.Diet.LargeAnimals.hippo.feed(), and all the hippos starve. * someone uses self.Zoo.Diet.buildings.visitor_reception.feed(), and ends up filling the reception with hippo food. (This might even be possible for someone who has no permissions on the reception object) * someone wants to have a dinner party; feeding more than one animal at once. But then he finds he has to switch to a different technique because he cant call his dinner_party() method with more than one context at the same time. * someone uses self.Zoo.buildings.office.printers.laserjet1.Zoo.Diet.LargeAnimals.hippo.feed(), and ends up feeding paper to the hippo. (that could even be someone who has no other permisions on that hippo object) Ive now nearly finished converting all my newbie zope projects back to a conventional O-O design. I have been bitten by all the problems listed above. The feed method *should* *be* implemented in a ZooAnimal base class. Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
Thats fine until:
<snip hilarious hippo metaphor> I liked that :-)) very accurately sums up some of the problems... Although I'm not sure they're problems with the method binding this thread was about. The problems you describe seem to be with Acquistion in general. Other than that, I don't have the answers :-( Any ideas, anyone? cheers, Chris
Chris Withers wrote:
Toby Dickenson wrote:
Thats fine until:
<snip hilarious hippo metaphor>
I liked that :-))
very accurately sums up some of the problems...
Although I'm not sure they're problems with the method binding this thread was about.
The problems you describe seem to be with Acquistion in general. Other than that, I don't have the answers :-(
Any ideas, anyone?
I think that the binding control will address many of the problems that Toby raised. It boiled down to this: - Some bits of code are designed to work on specific objects or kinds of objects. The binding control will allow authors to make sure that these are applied to the expected objects. - Some bits are designd to be reusable in any context. Authors will still be able to create these. Note that authors will be able to do this even when the bits are used as "sub-templates". Jim
Toby Dickenson wrote:
On Fri, 20 Oct 2000 12:54:19 +0100, Chris Withers <chrisw@nipltd.com> wrote:
Consider the following passage in the documentation:
Noooooo - Context-based instance-space applications are a major source of pain, bugs and security holes. They might be the one thing that Zope does different (and therefore they need to be explained) but that doesnt make them right.
I'm not sure I grok what rightness has to do about it. I think this is right, to me wrong == broken. This is not broken.
Thats fine until:
* someone adds an property named feed to an object at an intermediate location in the containment heirarchy. This breaks the cron job that calls self.Zoo.Diet.LargeAnimals.hippo.feed(), and all the hippos starve.
This is the classic anti-acquisition argument, but it's a red herring. The same argument applies to inheritance; introducing an attribute between two classes in a generalized relationship and your app breaks and all the hippos starve anyway. Zope cannot be robust against programmer error. Nothing can.
* someone uses self.Zoo.Diet.buildings.visitor_reception.feed(), and ends up filling the reception with hippo food. (This might even be possible for someone who has no permissions on the reception object)
This is once again programmer error.
* someone wants to have a dinner party; feeding more than one animal at once. But then he finds he has to switch to a different technique because he cant call his dinner_party() method with more than one context at the same time.
Can you explain this some more? I'm a bit lost on how this invalidates context vs. containment when binding methods. You're right, you can't have more than one context at a time, but neiter can you be bound to more than one container. If you want to feed more than one animal, use a loop and iterate over them.
* someone uses self.Zoo.buildings.office.printers.laserjet1.Zoo.Diet.LargeAnimals.hippo.feed(), and ends up feeding paper to the hippo. (that could even be someone who has no other permisions on that hippo object)
This is the same as your first two arguments: programmer error.
Ive now nearly finished converting all my newbie zope projects back to a conventional O-O design. I have been bitten by all the problems listed above. The feed method *should* *be* implemented in a ZooAnimal base class.
Ok, that's a valid approach. -Michel
Chris Withers wrote:
From: Michel Pelletier <michel@digicool.com>
Hmm. I thought this was a internal series of emails, I just now noticed that zope-perl got cc:ed on them somewhere in the middle. Oh well, it is some good discussion; I allways like to stir the shit! -Michel
participants (10)
-
Chris Withers -
Jeffrey P Shell -
Jim Fulton -
jpenny＠universal-fasteners.com -
Ken Manheimer -
Michael Bernstein -
Michel Pelletier -
Rik Hoekstra -
Steve Waterbury -
Toby Dickenson