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] Michel's Reply
Toby Dickenson wrote: > > On Fri, 20 Oct 2000 12:54:19 +0100, Chris Withers <[EMAIL PROTECTED]> > wrote: > > >>Consider the following passage in the documentation: > > Noo - 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 ___ 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] Re: Michel's Reply
Chris Withers wrote: > > >From: Michel Pelletier <[EMAIL PROTECTED]> > > 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 ___ 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 2.0 and Zope Status?
What's the current state of Zope with Python 2.0? My current understanding of the issues is: - Problem with ExtensionClasses and 2.0's circular reference GC. Can someone elaborate on this? Is configuring python2.0 with the --without-cycle-gc flag a sufficient workaround for now? - Python 2.0's cPickle and cStringIO should be used instead of the Zope-supplied versions. Is that it? Anything else I'm missing? Thanks. ___ 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] Re: [Zope] IIS and PCGI
Well I fixed this using a ISAPI filter which I will release soon (once I have some time) that takes a url /a/b/c/x.pcgi/f/g/h, and passes /a/b/c/x.pcgi to IIS so the file will run and /f/g/h to Zope. My next question is has anyone succeeded in getting this to work to another box over a mapped or shared win32 drive? I mapped g:\ to my zope host, and then specified PCGI_PUBLISHER=g:\pcgi\pcgi_publisher.py in my pcgi file. The problem seems to pcgi-wrapper.exe which does not like a mapped drive. (line 485 of parseinfo.c keeps spitting out missing publisher)... Thanks in advance and apologies for the cross post to zope-dev but it is more of a zope-dev question. - Original Message - From: "Andy McKay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 17, 2000 1:33 PM Subject: [Zope] IIS and PCGI > Im fiddling with IIS and PCGI, I've looked at > (http://www.zope.org/Members/brianh/iis_howto) the docs and got the server > to work correctly in that http://127.0.0.1/zope.pcgi is the same as > http://127.0.0.1:8080/ > > However it doesnt seem to be carrying through the trailing path info (or / > 's) for example > http://127.0.0.1/zope.pcgi/manage brings up 404. Using IIS 5.0, Win2k, Zope > 2.2.1. > > Anyone encountered this and know the solution? > > Thanks. > -- > Andy McKay, Developer. > ActiveState. > > > ___ > Zope maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) > ___ 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] FYI: away for a few days
I'm going to be out of town for a few days, and won't be as quick to respond to e-mails, if I respond at all during that time. Ty will still be around, though, to answer all your ZPatterns and LoginManager questions. Right, Ty? ;) ___ 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] Object references from dtml
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ender > Sent: Thursday, October 19, 2000 10:13 PM > To: Ross Boylan > Cc: [EMAIL PROTECTED] > Subject: Re: [Zope-dev] Object references from dtml > > > Ross Boylan wrote: > > > > I have a log composed of sublogs, and so on. I would like for > people to be > > able to see some kind of summary (e.g., short versions of the > logs down n > > levels) on the screen and then click on one of interest and see a fuller > > display of it. > > > > Is there a good way to do this using dtml? > > > > I've thought of two approaches. The "standard" zope > > having recently debugged company's zope server, i can safely say that > there is no 'standard'. > > > way seems to be to > > make each log folderish, and give each entry an id. Then I can > embed the > > address in the html. The problem with this is that I would > have to make up > > the id's and add extra machinery that the logs don't really need. > > > I'm leaning toward a second approach, of getting an object id > and putting > > it in the html. This also raises some issue. > > you lost me. your problem with the first method is having ids for your > log entries and your second method starts with getting ids for your > objects. The first method involves my creating and managing object id's. Since this is presumably done by the system anyway, I'd rather use the system's. Also, the first method involves having to add the "id" variable to each entry, and folder capability to each container, and so on. (Most of the entries are simultaneously containers). > > > looking ahead, YIKES, you just went from can i do this in dtml to > messing with python code in the guts of the ZODB. that was a SERIOUS > leap. IMO i'd highly recommend against messing with the zodb stuff, _p_ > attrs are supposed to be reserved. i understand you want to treat them > as read only, but i wouldn't even go near it if it could be implemented > easily otherwise or i had developed a strong masochistic tendency and > already knew the zodb well (well enough to know the answers to the below > questions). > > > This also raises some issue. > >* Will the id be stable in the face of the db potentially > > dematerializing objects underneath? > > what id? The question is general, but I presumably have a choice of two id's: the regular python object id and the persistent object id. The question is asking whether the regular id or the persistent id are stable. I presume the former is not (if you're using the db), while I hope that the latter is. > > >* If I use a persistent id (_p_oid, I think), will that be stable? > > see above commentX2. > > >* (Also, I'll need to be sure everything has persisted, but I think I > > can do that by forcing a transaction end before getting the _p_oid). > > transactions are important, but also telling it before hand that the > object is dirty and needs to be saved. you might want to read jim's > paper on the zodb. it and alot of other good material are linked from I think I've read them all. Dirtyness is not a problem, since the only objects that might lack a _p_oid are new ones. I don't know at what point they get created, so I figure I want to force a commit to assure they have meaningful values. > > http://www.zope.org/Members/itamar/LearningZope/LearningZope.html > > >* Can I map from object id back to object? > (_p_jar.something or other) > > this is getting worse(scarier?) as i go on... i have no idea. consider > also that a url is also a unique persistent object id that maps into the > zodb, why your first method works. > > >* Will this be robust across database changes (minimally, > from ZODB to > > ZEO)? > >* Will the object id consist of characters which can be > embedded easily > > in html? > > > > ... > > there are alot of other ways to do this... of the top of my head > > you could always store log entries in a sql db. I want to avoid relational db's. They are particularly ill-suited to this task, which involves deeply nested, heterogeneous object graphs. > > since you seem not adverse to doing it in python, despite your original > question... Oh, I'd much rather be doing python. I only bring up dtml because I need to display something the user can see. So d/html is the presentation language, and I need some way of associating gui elements with objects. > > so why not just write a python class for the log folder thats > persistent, add some methods for managing/storing log entries in a some > attr (maybe list of dicts) of the logfolder. write some dtml accessible > accessor methods to the attrs. write a dtml page for summary and one for > details. That might be the best solution. As I say, it just seems silly to be recreating an oid scheme when we've already got a couple of them. > > kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No c
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] Re: Hippo Feed and Acquisition
Chris Withers wrote: > > Toby Dickenson wrote: > > Thats fine until: > > > > > 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 ___ 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] Michel's Reply
On Fri, 20 Oct 2000 12:54:19 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >>Consider the following passage in the documentation: Noo - 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 [EMAIL PROTECTED] ___ 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] Hippo Feed and Acquisition
Toby Dickenson wrote: > Thats fine until: > 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 ___ 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] My $0.02
> >From: Michel Pelletier <[EMAIL PROTECTED]> > > >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 ___ 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 )
[Zope-dev] Michel's Reply
>From: Michel Pelletier <[EMAIL PROTECTED]> > >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. >> >> 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". > > > >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 comm
[Zope-dev] Method binding
Maybe the Zope-Dev guys have comments on this > >From: Jim Fulton <[EMAIL PROTECTED]> > > > >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. > > > >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". > > > > > >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 ___ 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] Object references from dtml
Ross Boylan wrote: > > I have a log composed of sublogs, and so on. I would like for people to be > able to see some kind of summary (e.g., short versions of the logs down n > levels) on the screen and then click on one of interest and see a fuller > display of it. > > Is there a good way to do this using dtml? > > I've thought of two approaches. The "standard" zope having recently debugged company's zope server, i can safely say that there is no 'standard'. > way seems to be to > make each log folderish, and give each entry an id. Then I can embed the > address in the html. The problem with this is that I would have to make up > the id's and add extra machinery that the logs don't really need. > I'm leaning toward a second approach, of getting an object id and putting > it in the html. This also raises some issue. you lost me. your problem with the first method is having ids for your log entries and your second method starts with getting ids for your objects. looking ahead, YIKES, you just went from can i do this in dtml to messing with python code in the guts of the ZODB. that was a SERIOUS leap. IMO i'd highly recommend against messing with the zodb stuff, _p_ attrs are supposed to be reserved. i understand you want to treat them as read only, but i wouldn't even go near it if it could be implemented easily otherwise or i had developed a strong masochistic tendency and already knew the zodb well (well enough to know the answers to the below questions). > This also raises some issue. >* Will the id be stable in the face of the db potentially > dematerializing objects underneath? what id? >* If I use a persistent id (_p_oid, I think), will that be stable? see above commentX2. >* (Also, I'll need to be sure everything has persisted, but I think I > can do that by forcing a transaction end before getting the _p_oid). transactions are important, but also telling it before hand that the object is dirty and needs to be saved. you might want to read jim's paper on the zodb. it and alot of other good material are linked from http://www.zope.org/Members/itamar/LearningZope/LearningZope.html >* Can I map from object id back to object? (_p_jar.something or other) this is getting worse(scarier?) as i go on... i have no idea. consider also that a url is also a unique persistent object id that maps into the zodb, why your first method works. >* Will this be robust across database changes (minimally, from ZODB to > ZEO)? >* Will the object id consist of characters which can be embedded easily > in html? > ... there are alot of other ways to do this... of the top of my head you could always store log entries in a sql db. since you seem not adverse to doing it in python, despite your original question... so why not just write a python class for the log folder thats persistent, add some methods for managing/storing log entries in a some attr (maybe list of dicts) of the logfolder. write some dtml accessible accessor methods to the attrs. write a dtml page for summary and one for details. kapil ___ 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 )
