Re: [Zope-dev] Re: Wishlist Item
OK, sorry about raising an issue that I was not around to comment on. First, there seems to be a good deal of confusion on what FileSystemSite or the DirectoryView portions of CMF are. They are simply a way to have Zope2 programmatic content stored directly on the filesystem, including dtml, page templates, python scripts and zsql methods, among others. FileSystemSite does not allow "filesystem access" in the usual sense, access is read-only; objects cannot be created on the filesystem through ZMI. Arbitrary filetypes cannot be easily stored on the filesystem at all (In fact I have no interest in that, I can always store such files in Apache-space.) This, or the CMF version, or something like it should be included because it is a large step up from pure TTW development in that it makes using conventional OS-level tools easier, including revision control systems and editors. It also gets the job done without all the effort of zope2 python based products. While products are important, and indeed, at this point the zope3 way, they don't scale down very well; and for one-off, will never meet the external world, systems; they represent a lot of wasted motion. FilesSystemSite and DirectoryView represent a "middle way" between pure TTW and pure file-system development. This is an idea that has come up at least three times, Ape was partially inspired by it, the CMF suite has such components, and it was thought to be worthwhile to pull out of CMF. CMF is a lot of overhead to pull in just to get DirectoryView, and exactly what to install to get DirectoryView and as little else as possible installed is not documented. In fact, neither is very well documented. I don't care whether DirectoryView, or FileSystemSite, or yet another implementation is blessed. However, the idea of permitting all programmatic content to be stored directly on the filesystem has merit and has been developed multiple times. It is an option that belongs in zope2 core. Note: if one is chosen, I will write a draft of a chapter for the "Zope Book" for the blessed implementation. jim penny [EMAIL PROTECTED] wrote on 03/26/2006 09:56:01 AM: > Tino Wildenhain wrote: > > > Maybe its just me but I personally dont like direct filesystem > > access in the core - if someone wants it, (s)he can pick from > > the 3rd party products - maybe there can be a list of recommended > > (active maintained) products? Direct access products should also > > carry some easily understandable warnings. > > I can understand that point of view for products that allow writing to > the filesystem, but, conceptually, what's the difference between > read-only "filesystem access" and a standard filesystem product? > > None, I think, but then I may have misunderstood the purpose of > FileSystemSite, and friends. > > Tim > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Wishlist Item
I don't particularly care one way or the other about ZClasses. However, I would like to see FileSystemSite made part of the base distribution. jim penny ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] python script
On Tue, Jan 09, 2001 at 10:12:36AM +, Chris Withers wrote: > Zope mailing lists wrote: > > > > I recently released 'zopectl', a python script > > ...gak... now is that a 'python script' or a 'Python Script'? ;-) > > *grinz* Damnnation, Chris, everyone knows that it is supposed to be spelled Python Thingy. "I recently released 'zopectl', a Python Thingy"... 'Please go wash your hands before your shake hands with me!' > > 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 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] Task, Job or Operation?
On Mon, Oct 23, 2000 at 03:07:25PM -0700, James Johnson wrote: > Is there a Wiki or some other starting point for this thread. As a > newbie I like safe vs power over anything else. I also understand > that with using anything in a power mode can be risky for a newbie. > It's nice to know that I can start out learning in a safe mode and > then graduate to a power mode after learning more. Is there a > ZopeScript and why not? Safe ZopeScript can be written in using other > scripting languages. Zopelet imho is not as marketable as ZopeScript. OK, this is the problem. There are several ways of writing executable code available to other objects in Zope. One is the Python Method. It is available from http://www.zope.org/Members/4am/PythonMethod >From 4am's page: PythonMethods will not allow assignment to an attribute, element, or slice. No "del" is allowed. Names starting with "_" are not accessible. Import is controlled. Globals all live in a private namespace. There is a proposal to call this construct a Zope Script. And your message is exactly the ammunition I wanted. Thanks! The other way to script in python is currently called an External Method. Since perl is being added as a Zope scripting option, this will clearly have to be renamed, as well. External Methods have none of the restrictions of PythonMethods. This makes it quite easy to escape all Zope security, to crash Zope, and to do other nasty things. Needless to say, Zope hosting sites do not generally provide External Methods. There is no ZopeScript, and probably never will be. What would ZopeScript do? Would it be a construct like JavaScript that was executed on the client's computer? If so, every browser vendor would have to support it. This is unlikely, to say the least. Is it server side? Then DTML, PythonMethods (to be renamed), PerlMethods (which don't exist yet), External (Python) Methods, External Perl Methods (which also don't exist yet) give plenty of scripting options, without the need for another language. It is not at all clear that Safe scripting methods (in the strong sense meant here, meaning that it can neither damage the client nor the server), can be written in languages other than Python (I have heard some doubts expressed about perl). And, there is generally no need to "graduate" to external (power) methods. You only need to use an external method when you need a module not imported by Zope (not available through the _ namespace). So, you have written several things in your message that really bolster my dislike for both zope script and power as terms. 1) You have gone from the word Zope Script to a separate language ZopeScript in a single bound. 2) You have assumed that you will want to "graduate" from Safe Methods to "Power" Methods (You don't, external methods are last resort options). 3) "Power" methods don't require a lot more learning than Safe Methods. You have to learn what modules are available, but you are using the same language in either case! Maybe my suggeston of flexible is to weak. Maybe they should be Escape Hatch Python Operations (Escape Hatch Python Zopelets)! > When you call it operation, method, or function it takes it away > from it's context. This is zope specific right? Excuse me while I > use safe ZopeScriptPython or power ZopeScriptPerl. Not really Zope specific in the sense you mean. It is an object (not in the OO meaning) that can be called from a Zope site. But the language is pure Python (perl), with no modifications, and usually can be snipped and executed outside of Zope. > > > Get your Free E-mail at http://tacoma.zzn.com > > Get your own Web-Based E-mail Service at http://www.zzn.com > > ___ > 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] Task, Job or Operation?
On Mon, Oct 23, 2000 at 11:08:14AM +0100, Chris Withers wrote: > [EMAIL PROTECTED] 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 > > > 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 ;-) OK, here is why I used Safe/Flexible. I still think that it is important to give newbies guidance as to which to choose. Because of the restrictions (no import, no _ variables, etc.) that Python Methods provide, it is far safer for a newbie to tackle Python Methods, and discarding them only when they are incapable of doing the needed operation. It is simply true that python methods ARE safer than external methods and ARE to be prefered if they have enough power. Hence the strong preference for Safe in the term. Now, what are things that stand in distinction to safe. One set is unsecure, risky, dangerous. No sane company is going to call a thing Dangerous Python Operation (even if true). So that set of associations is out. Another set of anti-associations is unprotected, open, unguarded. While this set is better, there are still too many connotations of danger. Another way of looking at it is that safe is similar to restricted (restrictions are enforced to maintain safety). Here the opposites are unrestricted, powerful, flexible. I don't like powerful here. It will encourage a newbie to skip the safe version entirely (what newbie doesn't want unlimited power?). Turbo, and supercharged imply extra speed, which I don't believe to be significant. Unrestricted has a double negative problem. Hence something like flexible. I really don't like Filesystem here. It is true. But, it provides the newbie zero guidance. Why should one use a Python Operation rather than a Filesystem Python Operation? The answer is nowhere to be found in the name (unless you count that the name is shorter!). I rather like the Zopelet suggestion. I would like to retain Safe/(some anti-association) in the name. This would give something like: Safe Python Zopelet Flexible Python Zopelet or Power Python Zopelet, or Filesystem Python Zopelet or something else. This is going on too long, but 2 more thoughts. The Safe version should appear in the pulldown before the corresponding Flexible/Power/Filesystem version. These lists are read by Euro-language readers fro top down and we want them to see the Safe version first. Another set of terms for this might be chosen from magick terminology, i.e. spell, incantation, cantrip. Then we could have grimoire/formula/cantrip. Such a nice set of terms! > > 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 )
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
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 )
Re: [Zope-dev] DISCUSS: XHTML Templates proposal
On Fri, Sep 15, 2000 at 04:55:53PM -0700, Paul Everitt wrote: > > [EMAIL PROTECTED] wrote: > > IMHO, view, page, and stylesheet don't make the grade due to > > conflicts/confusion with unrelated technologies (e.g. MVC, "server pages", > > CSS, etc.). > > On the other hand, reading the "What is styles?" material at: > > http://www.w3.org/Style/ > > ...makes me think that the goals of the people using these things (site > designers) are the same as the goals of the audience described for > stylesheets. That is, these are things that control the presentation. > > --Paul This might be a great idea, but..., could we have a pledge that DTML not be killed? It might prove to be a real inconvenience (understatement) to those of us who are abusing Zope to do general web application work (and don't really care about site design, in the usual sense of the word)! DTML might be an ugly, warty, hard to believe it sprang from Python little beasty, but it is a familiar little beasty. (And thanks for giving it to us, by the way!) > > ___ > 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] Traceback
How hard would it be to add more of the called URL to the traceback? Background: I have been developing relatively baroque SQL sites for internal use and find that when I am making changes to facilitate re-use higher up in the hierarchy, it can be relatively difficult to find out what failed. For example, I get this traceback: Traceback (innermost last): File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ElementWithAttributes) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/OFS/DTMLDocument.py, line 170, in __call__ (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/DocumentTemplate/DT_Util.py, line 337, in eval (Object: product_number) (Info: product_number) File , line 0, in ? NameError: (see above) Great, I know that I have not put product_number in as a cookie or a hidden value, and it could not be found by acquisition. It failed in rendering index_html. But there are 5 index_html's it could have failed in. How hard would it be to change the error message to say: Traceback (innermost last): Exception raised while constructing http: . . . 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] Z SQL: "optional" isn't?
On Fri, May 26, 2000 at 02:59:38PM -0500, Kyler B. Laird wrote: > > I'd like to build a Z SQL method for *many* > people to use to list courses that we offer. > I don't want to require that all queries > using it understand all of the columns, but > I do want to be able to modify the query in > many ways. > > So...after reading > http://yyy.zope.org/Documentation/Guides/ZSQL-HTML/ZSQL.1.5.3.html > optional > > A flag indicating if the test is optional. > If the test is optional and no value is > provided for a variable, or the value > provided is an invalid empty string, then > no text is inserted. > I thought I could just use "optional" > with all of my sqltests. > select * from course_catalog > > > > > > > > > > I have never used that corner of ZSQL methods. I have a guesses. I think that the method is working fine, but the nature of HTTP posting is giving you trouble. Remember, a REQUEST typically only contains non-null fields. There are three suggestions on fixing this. 1) preseed the calling form by putting in a BEFORE the form. This way, normal acquisition will get you an empty string even if there is no value entered in the form. 2) A bit more of a pain, but certainly doable. Remember that you can use ordinary logic in a ZSQL method. You can use choose among multiple cases in a single method. But, here you have 16 cases, which is unpleasant. Is it really true that ALL of these can be simultaneosly empty? 3) Considerable more pain, with some loss of safety. Construct the body of your method on the fly. Pass it in as an argument, and call that. For certain forms, this is necessary (if for example the user can modify the form generation process). ___ 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 )
