[Zope-dev] Plain Ice Cream
Michel Pelletier wrote: Python Function is not quite right, as it is fairly common (for me, at least) to define some helper functions in a Python Method. But it is better than Python Script. That's a good point I hadn't thought of :-S Function is just as technical as method. These are OO techncial programming terms (function less than method). The idea is to lower the bar for people using Zope. People who only know HTML will be much more likely to grok what a script is than a method. We want to avoid elitism. Method is total OO elitism, function less so because it's very language neutral, and script is like plain vanilla ice cream, everyone gets it. No offence, but I don't think any of the above paragraph holds any weight. People who only know HTML won't be writing Python(Method/Function/etc)s anyway. I don't think any out of 'script', 'method' or 'function' will have more meaning than any of the others to these people. These are just words we're talking about, to the non-technical, it's not actually going to matter what they are. The main point is to avoid confusion, especially where words have associated meaning for technical people. That, IIUC, is why this discussion started in the first place... Like chocolate and coconut-shaving covered almonds, technical details mixed in with your ice-cream will appeal only to a smaller crowd. Vanilla Ice cream gets boring quickly! This ain't a good metaphor for your argument ;-) The new DC documentation motto is "Explain key ideas in simple terms." Method is not a simple term. Can you please make sure this doesn't become 'use less meaningful/incorrect vocabulary in an attempt to keep it simple, and so ending up with even more confusing terminology' ;-) cheers, Chris ___ 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?
[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 Nah, they have too many cron-esque associations. Sounds like things to be found on a to-do list on in a schedule of some sort. Safe Python Subtask :-( Then external methods, which are often also not methods, can become Flexible Python Task Well, felxible doesn't really explain a lot. Filesystem is probably the most explicit. I dunno, I actually like Jeff's suggestion of Operation giving you: PythonMethod- Python Operation External Method - Filesystem Python Operation The same could also apply to DTML and Perl Methods. A nice side effect is that you could have Filesystem DTML Operation replace those horribly named HTML File objects you get when use grab your DTML out of .dtml files on disk. Especially as they bypass all known security ;-) cheers, Chris ___ 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] Block'ed
Michael Bernstein wrote: The diference (for me) between a View and a Block is whether they are intended to be accessed directly by a client (browser). Blocks also tend to be reuseable in many views (I typically have a Block (DTML Method) called main_navigation, for example), and can be composed of other Blocks. Views like index_html may be reused, but usually through acquisition, not recomposition. I like the idea behind blocks, I think it's probably the best name yet and described how most people use things like PythonMethods, external method and DTML Methods :-) cheers, Chris ___ 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
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. Let me persuade you. * 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. I used to believe that too, but no longer agree. I changed my mind after developing a large application in Zope, and spending alot of time firefighting the problems that it caused. 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. This analogy is false. If a programmer is responsible for a class and it becomes broken in that way then yes, he is at fault. Fortunately there are well understood principles for design inheritance relationships to keep this easy. Each project has a finite number of classes. Each class has dependencies to only a small number of other classes. Testing (is used appropriately) can be used to ensure correctness, and this probably means re-testing each derived class when a base class changes. The same is not true of a containment heirarchy. The containment heirarchy is managed by content managers, who are responsible for content. After adding content they might test that content, but they are unlikely to retest any functionality - its not their responsibility. The containment heirarchy is often large and sprawling. Acquisition-based bugs occur on a per-instance basis, not per-class, and typically there will be very many more instances in a system than there are classes. After a change to an instance there is a need to re-test *every* *instance* below the change in the containment heirachy. (When was the last time you changed your root folder? Did you test your whole site?). This makes it impractical to test them all. You raised the question of whether this is an anti-acquisition argument or a containtment-vs-context-binding argument. Please dont misunderstand me; acquisition is great when used appropriately. However if methods bound to containement then acquisition could not be used for the purpose you are demonstrating here. Zope cannot be robust against programmer error. Nothing can. I, as a programmer, develop Zope products. My users install them on their system. If your users are programmers then this comment is relevant, but I dont. Adding a property to an object (using the Property tab in the management interface) is a user-level operation. I do expect my systems to be robust against user error. (Note that it is even possible to 'break' Zope's own management interface by adding some carefully named properties. Some of those are even WikiNames ;-) * 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. Do you mean the programmer who implemented 'feed'? If yes, Im pleased you agree with me. Their mistake was to use acquisition instead of inheritance. If they wanted to use acquistion then they would need to augment their otherwise simple implementation of 'feed' with either: 1. Explicit security checks (hard to get right) 2. Explicit is_instance checks (inflexible) 3. Accept the fact that anyone granted the 'Feed Hippos' permission on any hippo may dump hippo feed anywhere, or feed other hippos for which they do not have that permission. Perhaps the hippo analogy isnt helping, so heres a more concrete example. In zope today it is possible for a user who has been granted the 'View Management Screens' permission in *one* folder to create a one-line dtml method that lets him see the management page of any other dtml method in the whole site. Why? because DTMLMethod's manage_main binds to context not containment. * someone uses self.Zoo.buildings.office.printers.laserjet1.Zoo.Diet.LargeAni mals.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. (Note: Michel is right that this one is not immediately relevant to the binding discussion; its purely a demonstration of a misuse of acquisition. Its also a programmer error, but in Michel is that programmer) The real problem here is that you are relying on acquisition from a context that is not a direct container. Each instance only has one containment heirarchy. However it has an infinite number of possible contexts, which are chosen by the caller. Suppose you have an (apparently correct) external method in Zoo: def feeding_time(self): self.Diet.LargeAnimals.hippo.feed()
[Zope-dev] Security Confusion :-S
If anyone can help me with this, it'd give me more faith in the new
security model :-S
Right, I have a Python Product Class (lots of bits left out ;-):
class MyProduct(OFS.SimpleItem.SimpleItem):
"""...
"""
__ac_permissions__=(
('Use MyProduct' ,('a_method',),('Manager',)),
)
a_methodisDocTemp=1
def a_method(self,ignored,md):
list = []
for name in self.get_contents():
list.append(DisplayClass(name,self))
return list
The important bits of DisplayClass look like:
class DisplayClass(Globals.Persistent):
""" """
__allow_access_to_unprotected_subobjects__=1
meta_type = 'CaseDisplay'
__ac_permissions__=(
('View',('get_name',),('Anonymous',)),
)
...
def get_name(self):
return self._name
Now, I have a DTML method which goes like:
dtml-with an_instance_of_MyProduct
dtml-in a_method
Bdtml-var sequence-item html_quote:/B
dtml-var get_nameBR
/dtml-in
/dtml-with
Which _always_ throws up an authentication box when a_method returns
anything except an empty list. no matter what username or password I
use, that box still appears.
What I would like is for the get_name and a_method methods to be mapped
to permissions so I can manage access to them using the security tab.
How should I do that?
BTW, in an attempt to get the method accessible in _some_ way I have
tried:
- setting __allow_access_to_unprotected_subobjects__=1 in both the
MyProduct and DisplayClass classes.
- setting get_name__roles__=None in the DisplayClass.
- giving every conceivable permission to both the Anonymous and Manager
roles in the folder containing the MyProduct instance
None of which feel like a good way to go, but nevertheless, none of them
worked.
The only way I coudl solve the problem was to give the DTML Method the
'Manager' proxy role, then everything worked fine.
Why is that?
What's _is_ going on?
Confused and Frustrated (isn't that always the way with Zope security?!)
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 2.0 and Zope Status?
On 20 Oct 2000 19:09:47 GMT, [EMAIL PROTECTED] (Ty Sarna) wrote: 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 That used to be a problem with some early cvs release, but it seems to have gone away now. Note that ExtensionClasses do not yet participate in the gc machinery, so cycles involving them can still not be collected. the --without-cycle-gc flag a sufficient workaround for now? I suggest this is the first thing you try if python faults during startup. - Python 2.0's cPickle and cStringIO should be used instead of the Zope-supplied versions. Yes. Is that it? Anything else I'm missing? There are several places where Zope is not defending against objects which raise an exception inside str(). This has not been a problem up to now, but 2.0's unicode objects expose the problem. The most serious possible effect is of terminating a publisher thread. Fixes for these bugs are bundled into my patches to support Unicode, at http://www.zope.org/Members/htrd/wstring Other than that, 2.0 is great. Ive been using it extensively for several months now without problem. 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 )
RE: [Zope-dev] Reference to a user
If I want to store a reference to a User in Zope, what's the best way to do it? I'm currently storing just the user's name, which doesn't seem very robust. Perhaps there's a more conrete reference to the user object? How about a path or something? Is there an interface for this anywhere? I guess something would have been needed for the ownership stuff? Any ideas gratefully recieved :-) You might want to look at the 'ownerInfo' method in lib/python/AccessControl/Owned.py. That produces a fully qualified 'path' to identify a user. It probably should be made an interface on the user object itself (it probably was done this way initially to avoid forcing authors of other user sources to implement a new method or be broken). Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.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 )
Re: [Zope-dev] Task, Job or Operation?
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. Ken [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 )
Re: [Zope-dev] Meaning :-S
Ken Manheimer wrote: Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( Chris . o O ( what the hell is a Zopelet? ;-) ___ 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] Reference to a user
Brian Lloyd wrote: You might want to look at the 'ownerInfo' method in lib/python/AccessControl/Owned.py. That produces a fully qualified 'path' to identify a user. It probably should be made an interface on the user object itself (it probably was done this way initially to avoid forcing authors of other user sources to implement a new method or be broken). Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com So, the following code (in a python product ;-) should get me a persistent reference to the user that I can store, say, in an SQL database: from AccessControl import getSecurityManager,Owned the_current_user_path = Owned.ownerInfo(getSecurityManager().getUser()) Which leaves me with one other question ;-) How do I turn the_current_user_path into a User object which I can use in the following: print the_user.getUserName() print the_user.getRoles(an_object) 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] Meaning :-S
On 10/23/2000 11:37 AM, "Chris Withers" [EMAIL PROTECTED] wrote: ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( The worse confusion is choosing a name that means something and then either o Having to explain that it means different things in different contexts, even within Zope. (This is a bigger problem with the name Method than the whole binding issue. Ditto for script. Instructing a user to write a Python Script will cause a Python programmer to go to the file system). o Having to explain "it's like ... but different..." This was apparently one of the other problems with the name Method, in that PythonMethods (the through-the-web variety) may or may not behave like traditional Methods in programming languages. This is especially bad when the code is Python since Python is also what we develop in. Python can now exist in many places in Zope (web, Extensions/, and Products (disk based)). External Methods were a nice name in that they connoted that it was a chunk of code that was external to Zope (at least the ZODB). The use of 'method' can come back into issue regarding how they got bound (ugh), but the External bit fit. If I was told "write an External method", I knew what that meant. When*ever* I hear someone mention writing a new python method to do something, it has to be qualified with "you mean in a product\class on the file system or a _PythonMethod_?" Function, Script.. They all fall prey to the same thing. Zopelets follows the cute naming of Applet, Servlet, Scriptlet... (IE has Scriptlets). I'm not advocating it entirely, but it follows a nice silly tradition in a way that is explainable - small chunks of Zope code managed through the web. And they happen to be in Python. (or could be predicated by the language of choice). Jeffrey P Shell, [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 )
[Zope-dev] PythonPiece, perlpiece. You can use the Big PP or the little pp!
Is it not just another piece of the puzzle to figure out? :-) 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] (no subject)
Hi Name Hunters, My problem with Zopelet is that it already has a meaning, at least to me. Looking down the road, not nearly as far as one might imagine, let's see where we may be heading. Think about minimal Zope instances running on Palm Gizmos, Cell Phones, whatever, a sort of personal ZEOClient, that enables offline or intermitent access to Zope Applications (e.g. WorldPilot). That's a Zopelet to me, a "little Zope". As for the other suggestions, "Op" sounds right to me. An Operation, or an Operative carrying out some work on behalf of the caller. Python Op, Perl Op, XSLT Op. It's short too! Also, Safe is clear, and easy to grasp, since most folks are aware how critical security can be. As for Flexible vs. UnSafe, how about "Direct", as in, "running directly from the file system"?. The term implies a trade-off of power for some degree of insecurity, at least to the initiated. Newbies should be warned away if they don't get the connotation. This leads to: Direct Python Op, etc. Later, Jerry S. ___ 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] Task, Job or Operation?
Sorry for the duplicate post, forgot the subject. :) Hi Name Hunters, My problem with Zopelet is that it already has a meaning, at least to me. Looking down the road, not nearly as far as one might imagine, let's see where we may be heading. Think about minimal Zope instances running on Palm Gizmos, Cell Phones, whatever, a sort of personal ZEOClient, that enables offline or intermitent access to Zope Applications (e.g. WorldPilot). That's a Zopelet to me, a "little Zope". As for the other suggestions, "Op" sounds right to me. An Operation, or an Operative carrying out some work on behalf of the caller. Python Op, Perl Op, XSLT Op. It's short too! Also, Safe is clear, and easy to grasp, since most folks are aware how critical security can be. As for Flexible vs. UnSafe, how about "Direct", as in, "running directly from the file system"?. The term implies a trade-off of power for some degree of insecurity, at least to the initiated. Newbies should be warned away if they don't get the connotation. This leads to: Direct Python Op, etc. Later, Jerry S. ___ 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] ZCatalog + ZCatalog
I am making it my mission to enhance the beast that is ZCatalog. This is the
first of many improvements I hope to make to it as time goes on.
DISCLAIMER
This patch has only been moderately tested, and all side affects are not
known. I am submitting it here for review before adding it to the collector.
You take full risk in using this patch on your installation.
/DISCLAIMER
OK, what this patch does is allow you to concatenate ZCatalog result
sequences (Lazy sequences) without loading the whole enchilada into memory.
It also dispenses with the funky workaround/hack notation that currently
exists (although it still works AFAIK). Once this patch is in place, you
will be able to write code as follows:
dtml-in "Catalog(args)+Catalog(other args)+..."
...
/dtml-in
or even:
dtml-in "Catalog1(args)+Catalog2(args)"
...
/dtml-in
The latter might be useful for dealing with ZCatalog scaling issues, or
combining completely objects from entirely different locations.
The patch changes Lazy.py and Catalog.py (very slightly). These files can be
found in your {Zopedir}/lib/python/Products/ZCatalog directory.
Add the following code into the Lazy class definition in Lazy.py. I added it
at the end following line 118 (slice=__getslice__):
def __add__(self,other):
# Concatenate result sequences together while remaining lazy
# Make sure the object we are concating is also Lazy
try:
if other.__class__.__bases__[0].__name__ != 'Lazy':
raise TypeError, """Cannot concatenate objects. Both
must be lazy result sequences (ie ZCatalog results)"""
except:
raise TypeError, """Cannot concatenate objects. Both must be
lazy result sequences (ie ZCatalog results)"""
if self.__class__.__name__ == 'LazyCat':
# Don't nest LazyCat objects unnecessarily
if hasattr(self,'_seq'):
seq = self._seq
else:
seq = [self._data]
else:
seq = [self]
if other.__class__.__name__ == 'LazyCat':
# Don't nest LazyCat objects unnecessarily
if hasattr(other,'_seq'):
seq = seq + other._seq
else:
seq = seq + [other._data]
else:
seq = seq + [other]
return LazyCat(seq)
The change to Catalog.py is a single line as follows:
Change line 603 (if not r: return r) to:
if not r: return LazyCat(r)
The change to Catalog.py prevents empty catalog search results from throwing
an exception when concatenating it with a non-empty search result. This is
the only part that I see as a risk to break existing code. If you, for
whatever reason, relied on a ZCatalog returning an empty list ([]) when the
search came up empty, your code will no longer work. Here is an example:
dtml-let result="Catalog(args)"
dtml-if "result == []"--- This no longer works
...
dtml-else
...
/dtml-if
/dtml-let
However this still does:
dtml-let result="Catalog(args)"
dtml-if result
...
/dtml-if
/dtml-let
And this does what you expect of it when both searches come up empty:
dtml-in "Catalog(args)+Catalog(other args)"
...
dtml-else
...
/dtml-in
IMHO this is a very minor side affect, and well worth the gain.
Please scrutinize this patch and pick it apart and let me know what works
and what doesn't or if I've missed something.
Enjoy,
Casey Duncan
___
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 )
[Zope-dev] Unit testing, ZUnit
We (I and Hiperlógica) started to develop a Product we called ZUnit, intended for XP-style unit-testing Python-based Products in a full Zope environment (with a real ZODB, REQUEST, RESPONSE, etc). We first conceived it as a kind of Zope-based version of unittestgui.py - you create a "TestRunner" object giving it the package, module and name of a TestSuite object generator (see the PyUnit documentation) and inside it you may click on some widget to run the tests and produce a "TestResult" object which you can inspect later. Does this sound like a good design? Then I figured in the long run a Product isn't the best sollution; instead, fiddling with App/Product* sounds more like it, to allow developers to register tests just like they register classes, ZClass superclasses, _misc and help. Of course, just like the current registerHelp and others, it wouldn't be mandatory and not using it wouldn't break anything. Then, in the Product's page in the Control Panel, there would be a tab "Test", where you'd be allowed to run the unit tests. What do people think of this? What does DC think of this? Can I go ahead and develop it in this direction? (I will create a proposal in dev.zope.org, but I want to get some feedback here first to flesh out the proposal a little more.) []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ 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] Unit testing, ZUnit
I would be very interested in such a beast. It's way too hard to do unit testing in Zope right now. I'm not sure about how it should be designed, but that's what the fishbowl is for. :-) - Original Message - From: "Lalo Martins" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 23, 2000 8:56 PM Subject: [Zope-dev] Unit testing, ZUnit We (I and Hiperlógica) started to develop a Product we called ZUnit, intended for XP-style unit-testing Python-based Products in a full Zope environment (with a real ZODB, REQUEST, RESPONSE, etc). We first conceived it as a kind of Zope-based version of unittestgui.py - you create a "TestRunner" object giving it the package, module and name of a TestSuite object generator (see the PyUnit documentation) and inside it you may click on some widget to run the tests and produce a "TestResult" object which you can inspect later. Does this sound like a good design? Then I figured in the long run a Product isn't the best sollution; instead, fiddling with App/Product* sounds more like it, to allow developers to register tests just like they register classes, ZClass superclasses, _misc and help. Of course, just like the current registerHelp and others, it wouldn't be mandatory and not using it wouldn't break anything. Then, in the Product's page in the Control Panel, there would be a tab "Test", where you'd be allowed to run the unit tests. What do people think of this? What does DC think of this? Can I go ahead and develop it in this direction? (I will create a proposal in dev.zope.org, but I want to get some feedback here first to flesh out the proposal a little more.) []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ 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] Meaning :-S
Chris Withers wrote: Ken Manheimer wrote: Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( Chris . o O ( what the hell is a Zopelet? ;-) I have to say that I don't like Zopelet either. I guess nobody else likes my 'Blocks' nomenclature: Python Blocks Perl Blocks DTML Blocks As I mentioned before, I tend to use DTML Methods in two contexts: - as Views on objects (Templates) - as building blocks for Views In one context (Views/Templates), the DTML method is meant to be accessed directly through the web. In the other context (Block), the DTML method is only ever accessed by a View. I would actually like to have a Block object that is not directly accessible, without having to go through some proxy-role rigamarole. Something else to consider for these two Use Cases of DTML/Python/Perl Methods/Blocks/Scripts, is that typically only the Block Use-Case is expected to be re-used through recomposition, as well as acquisition, while Templates/Views are usually re-used through Acquisition only. I'm not sure this has any impact on the 'Method Binding' argument floating around, but I thought I'd mention it again in that context. HTH, Michael Bernstein. ___ 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] Security Confusion :-S
On Mon, 23 Oct 2000 15:59:24 +0100, Chris Withers [EMAIL PROTECTED]
wrote:
(untested hints to follow)
class MyProduct(OFS.SimpleItem.SimpleItem):
"""...
"""
__ac_permissions__=(
('Use MyProduct' ,('a_method',),('Manager',)),
)
a_methodisDocTemp=1
def a_method(self,ignored,md):
list = []
for name in self.get_contents():
list.append(DisplayClass(name,self))
list.append(DisplayClass(name,self).__of__(self))
return list
The important bits of DisplayClass look like:
class DisplayClass(Globals.Persistent):
class DisplayClass(Globals.Persistent, Acquisition.Implicit):
""" """
__allow_access_to_unprotected_subobjects__=1
meta_type = 'CaseDisplay'
__ac_permissions__=(
('View',('get_name',),('Anonymous',)),
)
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 )
Re: [Zope-dev] Unit testing, ZUnit
What do people think of this? you get my vote 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 )
[Zope-dev] The Great Python (and Perl) Method Renaming Poll
We will be conducting a community poll to decide what to call Python (Perl, insert your language here) Methods. Many candidates have been discussed, but I'm afraid I don't have enough time to cull all the candidates from the discussions. So, before the poll, we are calling for nominiations from the community. Please send me an email containing one or more candidate names. These names will be added to the list. No pre-screening will be done, so please exercise some discretion if your favorite name is more tounge-in-cheek than practical (you never know what the masses will decide though!). Later this week, I will create a web poll where you can vote for your favorite. 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 )
