Re: [Zope-dev] Python and Perl scripts
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Python and Perl scripts
Michel Pelletier wrote:
>
> [EMAIL PROTECTED] 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
_
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] Python and Perl scripts
[EMAIL PROTECTED] wrote: > > 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Python and Perl scripts
On Fri, Oct 20, 2000 at 02:18:47PM -0700, Michel Pelletier wrote: > [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] > 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 ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Python and Perl scripts
[EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Python and Perl scripts
On 10/20/2000 12:02 PM, "[EMAIL PROTECTED]" 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, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Python and Perl scripts
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 <[EMAIL PROTECTED]> > > >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 - [EMAIL PROTECTED] > 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 ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Python and Perl scripts
This one is probably the most useful of the lot ;-) >From: Michel Pelletier <[EMAIL PROTECTED]> >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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
