[Zope-dev] Python 1.6
I'm about to start looking at running Zope on python 1.6 (Im feeling the need for better Unicode support). Has anyone tried this? 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] Python 1.6
On Fri, 23 Jun 2000 21:27:43 +0200 (CEST), Dieter Maurer <[EMAIL PROTECTED]> wrote: >Toby Dickenson writes: > > I'm about to start looking at running Zope on python 1.6 (Im feeling > > the need for better Unicode support). >Almost surely, it will work. > >But it probably will not use the Unicode support automatically. That much I do know. I'm migrating to 1.6 so I can add this support to Zope ;-) (fyi, my prototype implementation for ZPublisher unicode support for python 1.5.2 is at http://www.zope.org/Members/htrd/wstring ) 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] Product author's guide to Zope 2.2+ is ready...
On Mon, 26 Jun 2000 11:25:51 -0400, Brian Lloyd <[EMAIL PROTECTED]> wrote: >As promised, I've written up a guide for product authors that >talks about the security changes in Zope 2.2+, what they mean >to product authors and how to ensure that your products work >with 2.2: Thanks, that is a useful resource. >http://www.zope.org/Documentation/How-To/ProductAuthorUpdateGuide/index_html But it has raised some questions.. Firstly, how does the presence of __allow_access_to_unprotected_subobjects__=1 in a class affect access to attributes in derived classes? Does it affect the whole instance, or just attributes of the class that includes it. In the following example I know subobject_2 is accessible, but what about the others? class a: def subobject_1(self): return 1 class b(a): __allow_access_to_unprotected_subobjects__=1 def subobject_2(self): return 2 class c: def subobject_3(self): return 3 class d(b,c): def __init__(self): self.subobject_4 = 4 def subobject_5(self): return 5 Secondly, I am confused that there have not been any security changes in ObjectManager.py and PropertyManager.py. As I understand it, the subobjects that they manage (ie properties and folder items) now fall into the inaccessible-by-default category. What am I missing? 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] Python 1.6
On Thu, 22 Jun 2000 08:02:29 +0100, Toby Dickenson <[EMAIL PROTECTED]> wrote: >I'm about to start looking at running Zope on python 1.6 (Im feeling >the need for better Unicode support). > >Has anyone tried this? FYI, Zope 2.2b1 compiles and runs well on python 1.6a2 on NT (the bits of Zope I'm using, at least) 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] BTreeFolder released
On Mon, 03 Jul 2000 16:51:23 -0400, Shane Hathaway <[EMAIL PROTECTED]> wrote: >I had some inspiration today and discovered a simple way to write a >BTreeFolder implementation. Wahay! >http://www.zope.org/Members/hathawsh/BTreeFolder/ > >It works better than I thought it would. It allows you to store >thousands (well, I've tested it with only 1536, but I don't know of any >limit) of objects with a user interface optimized for such a large >folder. I'm interested, but don't have time to install it at the moment. Could someone post a gif of it's user interface please? 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] Proposed interface: Restricted creation
On Wed, 05 Jul 2000 19:42:38 +0300, Itamar Shtull-Trauring <[EMAIL PROTECTED]> wrote: >Shane Hathaway wrote: > >> The place where this is needed most (IMHO) is for ZClass factories. So >> there needs to be a way to create meta type filters through the Web. > >Yes, but in Python products too, where you have Items that should only go in >specific ItemHolders. This is very common. I have a beautiful hack to do this for python products.. Firstly, this code goes in your product __init__ def register__class(context,klass,**kwargs): meta_type = _register_product_specific_type(context,klass,kwargs) if meta_type: _meta_types_registry = _meta_types_registry+(meta_type,) def _register_product_specific_type(context,klass,kwargs): """Hijack and abuse the product registration system for our own product-specific type. The mechanism for creating instances of this product is established, but the type is not entered in the global availability list. """ # Register the class old = Products.meta_types[:] apply(context.registerClass,(klass,),kwargs) new = Products.meta_types if new[:-1]==old: # A new meta_type was added to the end of the global list, as expected. # Remove it, and return it Products.meta_types = old return new[-1] else: # Something unexpected happened. The safest thing to do is leave it alone return None Then, in your ObjectManager derived container, add def all_meta_types(self): return _meta_types_registry Then use register_xxx_class(context,.. in place of context.registerClass. 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] Re: Acquisition (was: [Zope-dev] Overriding a method in an instance.)
On Mon, 10 Jul 2000 13:14:17 -0400, Shane Hathaway <[EMAIL PROTECTED]> wrote: >P.S. I wouldn't mind if someone posted this as a HOWTO. :-) I think theres two, slighly different versions in already HOWTOs ;-) Any chance of getting this into the Zope distribution? 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] Python 2.0 Unicode support
Announcing version 0.3 of the patches to add Unicode support to Zope. http://www.zope.org/Members/htrd/wstring This version uses the built-in unicode support new to Python 2.0 to provide Unicode strings in ZPublisher, property pages, and property sheets, and DTML. Any feedback gratefully accepted. Toby Dickenson ___ 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] Re: [Zope] Optimization and speed
On Sat, 15 Jul 2000 13:19:33 -0700, Stephan Richter <[EMAIL PROTECTED]> wrote: >I take that back in the previous mail to Steve about the large table. We >have one and I split the header from the rest as you suggested. But since >it is not streaming the information, it will still pop up all at once. What you describe is true: Zope will not start sending the page until it is finished calculating. If one bit of your page takes a long time to calculate then the user will see *nothing* until that is complete. However, I don't think this limitation is affecting you. You say the page displays quickly when viewed over DSL - the connection bandwidth doesnt affect how long the page takes to calculate! A modem user will receive the first few bytes equally quickly - it just takes them longer the receive the rest. 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] Wstring
On Mon, 17 Jul 2000 21:05:06 +0800, "Sin Hang Kin" <[EMAIL PROTECTED]> wrote: >hello : > >Does anyone known how to patch Zope2.2 for Wstring? If you mean my wstring patches that were developed for 2.1.6, you will find some updated patches at the original location, www.zope.org/Members/htrd/wstring The current patch (version 0.3) is incompatible with the previous ones (but this time it 'feels right'. I plan to keep this interface stable). It needs python 2.0, and uses the new built-in unicode type. 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] Python 2.0
Is anyone else using Zope with python 2.0? (on NT, fwiw) I am occasionally seeing protection faults as Zope starts up. When it happens, the fault is repeatable until I truncate data.fs. There may be some correlation to changing a help file (Zope's new help system will reindex its help files at startup if any have changed). Annoyingly, the it doesnt happen with a debugging build. Is anyone else seeing this? Or not seeing this? 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] Python 2.0
On Fri, 21 Jul 2000 16:29:23 +0100, Toby Dickenson <[EMAIL PROTECTED]> wrote: This problem goes away if I don't compile python with garbage collection support. I guess I shouldn't be suprised. >Is anyone else using Zope with python 2.0? (on NT, fwiw) > >I am occasionally seeing protection faults as Zope starts up. When it >happens, the fault is repeatable until I truncate data.fs. There may >be some correlation to changing a help file (Zope's new help system >will reindex its help files at startup if any have changed). > >Annoyingly, the it doesnt happen with a debugging build. Is anyone >else seeing this? Or not seeing this? > >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 ) 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] PATCH: Expanded "access" file
On Sat, 22 Jul 2000 20:48:28 -0500, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 01:27 PM 7/19/00 -0500, Phillip J. Eby wrote: > >>Hm. I don't think this could be classed as a "minor" change, however, >>since it has impact on ownership, for example. What's the path of the user >>folder which is above "/", for example? The whole thing is useless if >>these extra users can't be owners, and the ownership machinery right now >>wants an access path. I think perhaps we should go the fishbowl route on >>this, if only to make sure that Jim doesn't have a heart attack when he >>gets back. :) > >Looks like I was wrong. This was in fact quite a minor patch. I've only >tested this lightly so far, but if anyone else wants to try it out, here it >is. Note that the new "access" file format looks like this: Woohoo. I figure this is a big advantage for my newbie zope managers. 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] ZODB....
On Tue, 25 Jul 2000 18:07:06 +0200, [EMAIL PROTECTED] wrote: >I want to develop an external program that can store and retrieve >an Object (such as a Person) in the ZoDB That sounds a bit cruel. >I tried the example that I found in the How to's but it doesn't works >In fact, I have the following message : >ZODB.FileStorage(file) >attribute Error : FileStorage > >-->But I have imported ZODB > >And, when I try to import ZODB.FileStorage : the program stops with the >following message : >TypeError : call of non-function type > >what's wrong ? You are trying to call an object, and that object is not callable. Normally that error message should include the name of the type of the object that is being abused >>> "hello"() Traceback (innermost last): File "", line 1, in ? TypeError: call of non-function (type string) Either you truncated the message when you posted the message, or there is something strange with the object's type. Unless you are using a pre-release python 1.6 or 2.0 - If so the name of your type might not get printed if it is unicode 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] Ids starting with _
On Sun, 30 Jul 2000 10:38:44 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >Dieter Maurer wrote: >> > I wonder why starting folders with _ is so bad in Zope? > >> In the time, when everything was allowed what was not explicitely >> forbidden, an easy way was necessary to forbid access. Jim >> (and, therefore, Zope) used: >> >> anything starting with "_" is private: no DTML access, no Web access. >> >> Now, with the change to a security policy "Everything is >> forbidden when not explicitely allowed", the need for >> such a rule based on naming dwindles. Maybe, it will disappear >> sometime in the future. That rules applies at a lower level. It removes the need to have special-case handling for the many low-level objects that should never be web-accessible. Almost all zope-manageable classes (and certainly Folders, that Dieter mentioned) use the old rule. This happens because they derive from SimpleItem.Item, which has __allow_access_to_unprotected_subobjects__. 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] permissions/authorization on non ZClass/product objects
On Wed, 2 Aug 2000 22:41:46 -0400 (EDT), Chris McDonough <[EMAIL PROTECTED]> wrote: >Karl, > >Two things come to mind: > >First, make sure you're returning the instances in the context of their >container, e.g. instead of: > >def returnstuff(self): >class foo: >pass >return foo() > >do > >def returnstuff(self): >class foo: >pass >return foo().__of__(self) If you want to do that, then you need to inherit the acquisition base class too def returnstuff(self): class foo(Acquisition.Implicit): pass return foo().__of__(self) >You may also want to try the magic: >def returnstuff(self): >class foo: >__allow_access_to_unprotected_subobjects__ = 1 >pass >return foo().__of__(self) > >in the class instances you return if nothing in them needs to be protected >by permissions in any way. Using __allow_access_to_unprotected_subobjects__ the object doesnt _need_ to have a context (although it might be useful for other things), so you can drop the __of__ 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] Feedback requested on SkinnableAndLocalizableObjects
On Tue, 8 Aug 2000 20:46:59 +0200, Martijn Pieters <[EMAIL PROTECTED]> wrote: >A few days ago, I requested for some feedback on the >SkinnableAndLocalizableObjects project, and got exactly none! I cannot believe >that I put down a flawless design here that nobody has anything to add to. A >few days more, and the implementation I'll have will be much harder to fit >your ideas. This is the pain of Wikis. Overlook one tiny email and you never know its there :-( 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] remote procedure calls to manage functions
On Wed, 09 Aug 2000 16:06:36 -0400, Jim Fulton <[EMAIL PROTECTED]> wrote: >That's interesting..Hm. ZClient has to marshal. I suspect that >xml-rpc wants some sort of optimization. xmlrpclib will by default use python's standard library xmllib.py for parsing, which is terribly slow. There is support for an optional C extension, which gave me a 12x speed increase. Check out the source for xmlrpclib.py for pointers. 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] Cache-bug in handling of files
On Mon, 14 Aug 2000 10:01:03 +0200, Peter Arvidsson <[EMAIL PROTECTED]> wrote: >So there is nothing else I can do but to make my files open in a new >window then... > >But what I dont understand is why IE doesnt send any If-Modified-Since >header? Shouldnt it always do that if the settings are not set to never >update cached files? Browser dont spontaneously generate If-Modified-Since - only if you include a Last-Modified header in the original response (Im not entirely sure whether or not they are allowed to) Note that Brian was observing that IE was not sending any request to the server - any request (even one that includes cache control headers) is going to involve a performance hit. Brian: could you repeat your test including the header cache-control: must-revalidate This certainly *should* have the desired effect of not letting IE display stale data. Ive covered the use of this header in some detail in a recent HowTo: http://www.zope.org/Members/htrd/howto/caching 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] Re: Zope security alert and hotfix product...
On Thu, 10 Aug 2000 14:15:29 -0400, Brian Lloyd <[EMAIL PROTECTED]>
wrote:
> The issue involves the fact that the getRoles method of user objects
> contained in the default UserFolder implementation returns a mutable
> Python type. Because the mutable object is still associated with the
> persistent User object, users with the ability to edit DTML could
> arrange to give themselves extra roles for the duration of a single
> request by mutating the roles list as a part of the request
>processing.
OK, so I can exploit this with something similar to
user.getRoles().append('A Role That I Dont Have')
But, why isnt the append method covered by the new
inaccessible-by-default 2.2 security rules?
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] Data.fs
On Sat, 19 Aug 2000 14:17:51 -0400 (EDT), Chris McDonough <[EMAIL PROTECTED]> wrote: >> Surely this raises some data integrity issues if you copy in >> mid-transaction? Or does an incomplete transaction at the end of the db >> just get thrown out, and the design of the db assure that only the end of >> the file gets updated? > >An incomplete transaction at the end of Data.fs gets ignored and >is subsequently overwritten by the next new transaction. Data is always >appended to the file. .except during an 'Undo', when one byte is rewritten in the middle of the file. 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] Methods with no __roles__ defined no always protected?
On Mon, 21 Aug 2000 12:15:24 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >The SquishSite class has a method called item_count() which is used on >one of the management pages. It currently isn't protected by any >permissions or __roles__ and yet it still works fine on the management >screen concerned. > >I thought this sort of thing was supposed to throw up an unauthorized >error in 2.2? No, for two reasons: Firstly, I assume your management page is a dtml file on disk, not a dtml object stored in the ZODB. dtml files bypass *all* security checks. Secondly, all objects that inherit from OFS.Item.SimpleItem (that is, almost all high level objects) have the __allow_access_to_unprotected_subobjects__ flag set. Your method would be callable from through-the-web dtml too. The basic rules of Zope security are fairly easy; its the exceptions that cause the problems. 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] aq_inContextOf/can anyone explain this zmonitor log?
On Mon, 21 Aug 2000 16:03:38 +0200, Bob Pepin <[EMAIL PROTECTED]> wrote: Yeah, this is a good one. Theres some debate in the Collector about whether this is actually a bug or not. In short, aq_inContextOf checks for nested aquisition contexts. It does *not* check for nested objects. It will return zero if you pass it parallel acquisition contexts, even if the objects are indeed nested. >>>> iee=app.iee >iee=app.iee >>>> iee.doc1.aq_inContextOf(iee) >iee.doc1.aq_inContextOf(iee) >1 This was what you expected >>>> iee.doc1.aq_inContextOf(app.iee) >iee.doc1.aq_inContextOf(app.iee) >0 Here the acquisition wrappers `iee` and `app.iee` are distinct objects. Here is the full story, and a patch to get it to work the other way. http://classic.zope.org:8080/Collector/1066/view (This patch used to work, but ive not used it since it was submitted) 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] New version of BTreeFolder
On Mon, 28 Aug 2000 20:41:05 -0700, Kapil Thangavelu <[EMAIL PROTECTED]> wrote: >i ran some basic tests comparing a btree folder against a folder. i'm >not sure about my testing methodology but here are the results. the test >code is at the end of this email. Im not sure this benchmark is measuring the things that a BTreeFolder should excel at One advantage of a BTreeFolder is that you can access *one* if its contained items without having to load *all* of the others. All of your tests iterate through the whole content. Secondly, it should be possible to add two items simultaneously without causing a conflict, however your creation test has no concurrency. 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] Call for a creation_datetime property!
On Wed, 6 Sep 2000 09:58:44 +1100 , "Jay, Dylan" <[EMAIL PROTECTED]> wrote: >It is really a painful thing to do without. I realize I can add this >capability to factories of my own objects but I don't want to have to create >my own versions of dtml-document and everything else just to ensure that a >creation date is kept. I've tried using transaction logs but this is very >dodgy for the following reasons. 1) An object can be created by many >different methods. Its guess work working out which created the object. 2) >The odb can be packed and then you've just lost your creation date. > >Can anyone give a good reason not to include this property as a standard for >all ZODB objects? I wouldnt want to pay the overhead for every ZODB object, but it would be useful for those standard content-storage objects; Files, Images, and DTMLDocuments. I seem to remember a creation date is stored for PTK documents? 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] Python 1.6, "Expected node type 12, got 312"
On Wed, 06 Sep 2000 13:48:09 +, "John Hayward-Warburton (Programming account)" <[EMAIL PROTECTED]> wrote: >Hi, > >Clean build of Python 1.6 (downloaded immediately following release >notification), clean build of Zope-2.2.1-src; > >Accessing /manage brings an error in gparse.py, line 293 (ast=sequence2ast) >, "Expected node type 12, got 312". > >Anyone else seeing this? Anyone know what it means? Yes, there was a bug in pythons parser module. If you are deperate to use 1.6 then you will need to compile an old copy of parsermodule.c. However, I recommend using the current CVS of python 2.0. This (and other) bugs have been fixed relative to 1.6 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] Wiki Pain
Since the beginning of this year DC have moved alot of debate and discussion out of mailing lists, and in to Wikis. http://www.zope.org/WikiCentral/FrontPage lists most Zope Wikis. Does anyone else find Wikis to be far less convenient than a good old mailing list? Ive been annoyed by the following characteristics: 1. No threading. On several occasions I have made comments in a Wiki that were subsequently ignored - I guess because they got lost in the mass of other edits. Recently people have been adding edits to the end of the page: This makes it easier to keep track of changes, but harder to catch up on a discussion when you come to it for the first time. 2. No personal replies. On several occasions I would have liked to email a comment personally to another contributer, but they didnt leave an email address. 3. No update notification. The one time I was update to keep up with a Wiki discussion involved the other participant always manually emailing a change notification. 4. Hard to keep track of many Wikis: Each wiki has its own 'whats changed' page, but even those are too coarse. 5. Too easy to fragment a discussion. On several occasions I have thought that a discussion had dried up, only to find out later on that it had moved to another page. 6. Too easy to miss the creation of a Wiki. On several occasions people have posted comments on zopedev questioning why noone has commented on their page - Noone knew it was there. This is particularly a problem because Wikis tend to get created sooner than a new mailing list would do, out of the desire to capture all discussion inside that Wiki. Mailing lists only tend to get created once there is enough traffic to justify them, and by then everyone is aware of the topic. 7. Too easy to loose content. On several occasions I have been unable to add a comments to a Wiki, either because www.zope.org would not let me login, or because its database was full. 8. Editing is painful. I have to use the browsers text field, and the whole Wiki page has to make a round trip with every change. 9. I never get the structured text quoting of python source right first time. 10. There are too many empty pages, because someone has clicked on a ? next to word that happened to be a WikiName. Useful pages lie hidden behind a sea of links to empty pages. rant ends. 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] I feel your Wiki Pain ;-)
On Thu, 14 Sep 2000 10:11:56 -0400, Chris McDonough <[EMAIL PROTECTED]> wrote: >A lot of the listed complaints are trying to be addressed by the >"WikiNG" proposal, which is (of course) in the Proposals wiki on >dev.zope.org. Yes, I was aware of that proposal, and I tried to avoid repeating issues that are already being discussed there. WikiNG is a better kind of collaborative-editing tool, but that seems to be fundamentally the wrong medium for debate. >> How about running the 'Discussion' parts of (in particular) dev.zope.org >> from ZDiscussions, ZUBB or Squishdot? > >This may be a good idea... What's wrong with a mailing list? Is this just a case of NIH? This thread has already been more productive than anything Ive done on a Zope Wiki over the last year, and taken a fraction of the effort. 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] Wiki Pain
On Thu, 14 Sep 2000 13:24:21 -0400 (EDT), Ken Manheimer <[EMAIL PROTECTED]> wrote: >On Thu, 14 Sep 2000 [EMAIL PROTECTED] wrote: > >> Since the beginning of this year DC have moved alot of debate and >> discussion out of mailing lists, and in to Wikis. >> http://www.zope.org/WikiCentral/FrontPage lists most Zope Wikis. Does >> anyone else find Wikis to be far less convenient than a good old >> mailing list? > >Convenient for what? Debate and discussion. I am particularly concerned with inception and development of projects on dev.zope.org >the wikis are just the best fit for part of the >job, right now.) Agreed; Im questioning only whether they are the best fit for *everything* they are being used for. 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] I feel your Wiki Pain ;-)
> | 1. No threading. On several occasions I have made comments in a Wiki > | that were subsequently ignored - I guess because they got > lost in the > > and from the WikiNG proposal: > >For more elaborate editorial and commentary annotations, i can >see layered documents, using mixin objects that provide a >tailored view on other or contained objects. The mixin would >be a layer by which annotations are associated with text >passages in the rendered subject document, like "the crit >system":http://crit.org does for arbitrary web pages. > >Overall, document authors could use a particular annotation >structure according to their needs. Eg, discussion objects for >points which can be discussed, or brief editorial passages to >give feedback, and author checkmarks for when they've satisfied >or refute the suggestions, etc. > > Annotation is a spiffy kind of threading. I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis. The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate* > | 2. No personal replies. On several occasions I would have liked to > > From WikiNG: > >- Attribution of changes for tracking > > With attribution, you can identify and could respond directly to the > author of a particular passage. It's useful for more, of course. Cool, I missed that one. > | 3. No update notification. The one time I was update to > > | 4. Hard to keep track of many Wikis: Each wiki has its own 'whats > > The ability to subscribe for notification (above) and/or to track what > you personally have seen, and not, is intended for this kind of thing. It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content. > | 6. Too easy to miss the creation of a Wiki. On several occasions > > My plans for notification subscriptions would be hierarchical, and > enable you to subscribe to events like creations of new wikis > within a > hierarchy - so if you subscribe at the top of the wiki space, > you find > out about any new wikis, while if you subscribe within the developer's > part of the space, you learn about new developers wikis. Etc. (This > was not covered in the WikiNG proposal - i was trying to avoid > including too many details, and failed miserably anyway...-) Im happy. > | 9. I never get the structured text quoting of python source right > | first time. > > The only quoting you need to know is example:: > > The two colons after the word "example" indicate that this > contained > block is all quoted. Ill remember that. Your proposed new attribution scheme would help too. > As i said in my last reply (but after you posted this, so you couldn't > have taken it into account), mailling lists as they stand don't work > for establishing growing structures. But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html >In some cases a mailing list will be setup for substantive, >large-scale projects. Otherwise existing mailing lists can >be leveraged (for now, use zope-dev for this). Perhaps I should rephrase my objection. The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion ___ 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, 15 Sep 2000 08:28:40 -0400, Paul Everitt <[EMAIL PROTECTED]> wrote: >Note On Jargon > > The choice of term for the presentation object has been contentious. > Right now the list of choices include: template, view, page, or > stylesheet. This proposal doesn't make the decision on the jargon. > Rather, the tier is usually refered to as the presentation. When a > choice has to be made, such as the Architecture section, Template is > used as the temporary choice. so-obvious-you-might-not-have-thought-of-it.. 'Presenter' 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] I feel your Wiki Pain ;-)
On Fri, 15 Sep 2000 11:27:33 -0400 (EDT), Ken Manheimer <[EMAIL PROTECTED]> wrote: >(Not sure that will scale, but creating new lists for each proposal >definitely won't scale. I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point. You cant do that with todays Wikis, which need to capture the whole discussion right from the beginning (IMO) >Note that there's been a *number* of places in this recent WikiNG >discussion where' i've cited existing passages that directly address >people's points. I don't mean to complain - i think that's one cost >increased by disconnecting the discussion and the document. I think you (inadvertantly) provide evidence for my objection that Todays Wikis fragment discussion. Speaking as the person who started this thread, I didnt realise my comments would affect WikiNG until you suggested the issue. The inclusive nature of a mailing list is what makes it a useful community resource. 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] I feel your Wiki Pain ;-)
On Fri, 15 Sep 2000 11:40:09 -0400 (EDT), Ken Manheimer <[EMAIL PROTECTED]> wrote: >Do you feel that weblogs are bad models for debates? I find the wiki and weblog tools available today to be inferior to mailman for debates, and it will take alot of work to develop WikiNG into a serious contender. I suspect the sticky points will be: 1. The ability to read without continuous network connection. 2. A user interface that is not encumbered with transatlantic http round-trips for each user interaction. >I think they're [weblogs] >pretty good least-common-denominators. >i see them [weblogs and wikis] as better than just >email... (Ive snipped those two comments out of context, and I hope it doesnt misrepresent Ken) I agree email alone is inadequate Please dont misunderstand me: I am *not* advocating that. Wikis work well for consolidating documents once a rough concensus has been reached. My preference is that the discussion leading up to that concensus takes place on zope-dev. 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] Quixote PTL
Is anyone using Quixote's PTL? http://www.mems-exchange.org/exchange/software/python/quixote/ It looks like it might be useful in the niche that involves too much logic for DTML, and too much joining-strings-together to make python (or PythonMethods) cumbersome. 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] RE: [Zope-ZEO] Advice
> > >But there are > > >really > > >two ways to do this, either of which is viable. > > > > 1. the right way ;-) > > > > >2. Code all of your logic using TTW stuff and Zope > components. Use the > > >Publisher.Test.test method to call methods of your > Zope components > > >in unit tests. > > > > Do you really think this is a viable approach for a product with a > > non-trivial amount of logic? > > I'm afraid we are getting way off the topic of ZEO here, > but... I think this > is important, so... [Agreed. Ill CC zope-dev and I suggest we continue there.] Sorry, I phrased my question ambiguously. I meant, do you think a TTW development approach is viable for applications with a non-trivial amount of logic? ___ 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] Testing Zope applications
On Mon, 25 Sep 2000 12:41:21 -0400, Jim Fulton <[EMAIL PROTECTED]> wrote: >But Zope.debug uses the Zope environment. Unless you consider ZServer >a critical part of the Zope environment. It is extremely >rare for the difference between something like ZServer and >ZPublisher.Test to have any noticable impact on the application >behavior. This skepticism has served me well; I have already submitted several reports & patches for bugs in Zope's ZServer.HTTPResponse.write implementation. Having said that, I do agree that for most applications this difference is not critical. [much snippage; I agree with it all] >> I dont see a way to test this constraint, and it has proven impossible >> to avoid the problems using design rules. I recently checked some of >> our recent products using strategically placed debugging __getattr__ >> hooks - with initially horrifying results. > >It sounds like this is a problem that needs to be addressed. >It's not really a testing problem, but an architecture problem Agreed. Don't all testability problems originate with architecture problems? (apart from the 'I cant be bothered; testing is boring' problem ;-) >I'm not sure exactly what problem you are refering to. It sound's >like an issue of depending on a specific acquired name and having >the name overridden with something bogus. Is that it? There are two related issues that conspire to make the problem hard: A. What you descibe above, that looks like it will be fixed in part by NO_SUBOBJECTS_OVERRIDE (which looks great). The outstanding issue is what happens when a new version of a product wants to add a new NO_SUBOBJECTS_OVERRIDE name (when objects of that name may already exist in old subobjects). In many cases these to-be-protected names are part of a product's API. http://dev.zope.org/Wikis/DevSite/Proposals/APINamingConvention suggests a naming convention for new API attributes. I suggested in the discussion Wiki that it should not be possible to create subobjects with an id of the form reserved for API attributes - but it seems to have got lost in the Wiki noise :-( > 2. There will be a new interface in Zope 2.3 that will allow > you to prevent a name from being used lower in a containement > hierarchy. This change is documented at: > http://dev.zope.org/Wikis/DevSite/Proposals/ReplaceableProperty. > The work has already been done and checked into CVS. I've asked Shane, > the author, to update the interfaces wiki to capture this change. B. A common mistake in DTML authoring is to look up a name in the DTML namespace when the context expected to contain the name is not at the top of the namespace stack. The bug goes undetected if the context at the top of the stack does not contain that name. I have found that this happens too frequently even for skilled authors, and is rarely detected in review. In summary: one namespace isnt enough. I suspect that this is the problem percieved by Andrew Kuchling (who started this thread back on zope-zeo). Our solution to this (successful so far) has been to replace DTML in any use other than Document Templates. (For me, the greatest horror is the name 'DTML Method'. The name 'method' implies a tight coupling to the instance that it is a method of, however it is possible for a DTML Method to execute in a context where all of it's instances attributes are masked by those of other objects. Urgh) 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] aq_inner: don't call it!
On Tue, 26 Sep 2000 11:32:17 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >After more playing I've discovered that calling the resutl of aq_inner() >appears to be a very bad idea ;-) > >The line: >print self.aq_inner() > >in the __call__ method of a python product caused the python process to >dump an 'unknown software exception'. > >Should that be so? I bet you are using python 1.5.2 on Windows. Python has a good try at catching too-deep recursion. In that version its limit was set a little too high, and Windows catches the error first. >Also, I thought aq_inner gave the contaiment context (presumably as a >list?) but it just returns a single object. >So, how can I get the containment context of an object as a list? Check out the implementation of getPhysicalPath 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] aq_inner crash: Python 1.5.2's fault? (also how to get the client)
On Tue, 26 Sep 2000 14:09:39 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >> I bet you are using python 1.5.2 on Windows. > >I am, Toby's explanation sounds accurate. So, does this go in the Zope >collector or the Python collector? >If the later, does anyone know if it is in there already? The latter, yes, and its long fixed. 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] Testing Zope applications
On Tue, 26 Sep 2000 07:42:29 -0400, Jim Fulton <[EMAIL PROTECTED]> wrote: >Toby Dickenson wrote: >> >> >I'm not sure exactly what problem you are refering to. It sound's >> >like an issue of depending on a specific acquired name and having >> >the name overridden with something bogus. Is that it? >> >> There are two related issues that conspire to make the problem hard: >> >> A. What you descibe above, that looks like it will be fixed in part >>by NO_SUBOBJECTS_OVERRIDE (which looks great). The outstanding >>issue is what happens when a new version of a product wants to >>add a new NO_SUBOBJECTS_OVERRIDE name (when objects of that >>name may already exist in old subobjects). > >I think that there should be some discussion of this design >pattern. Specifically, I'm not sure I like the idea of an application >that depends on fixed names in a hierarchy. In fact, I know I >don't. :) The technique isnt nice, but its hardly unconventional. the REQUEST object (as in self.REQUEST) is a good example. >*I* would like to see this discussion happen in a Wiki, >but I won't insist. :) FWIW, it will be much more likely >for me to make comments in a wiki, especially if someone >sends me the wiki link when they are ready for comments. I start something later this week. 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] Testing Zope applications
[on the subject of dtml picking the wrong context to look in first]
>>> I dont see a way to test this constraint, and it has proven impossible
>>> to avoid the problems using design rules. I recently checked some of
>>> our recent products using strategically placed debugging __getattr__
>>> hooks - with initially horrifying results.
Try applying this patch, which highlights every instance where it may
be possible to subvert the behaviour of a Zope application by adding a
carefully named property or subobject to the root folder.
A few minutes browsing through the management interface picked up over
200 incidents, listed at http://www.zope.org/Members/htrd/names
Many of these may be innocuous (and most are variations on a theme),
however I am sure that many are undiscovered bugs.
*** Application.py 2000/07/21 09:45:37 1.1.1.3
--- Application.py 2000/09/26 14:36:04
***
*** 194,201
--- 194,207
def title_and_id(self): return self.title
def title_or_id(self): return self.title
+ def __getattr__(self,id,reg={}):
+ if not reg.has_key(id):
+ print `id`
+ reg[id]=id
+ raise AttributeError(id)
+
def __init__(self):
# Initialize users
uf=UserFolder()
self.__allow_groups__=uf
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] more __call__ ...
On Tue, 26 Sep 2000 16:11:50 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >So, if I give my product a class attribute of isDocTemp=1, what >signature should I give my product's __call__ method so it picks up the >DTML namespace? Interestingly, Ive just put a HowTo that does this <http://www.zope.org/Members/htrd/howto/FunctionTemplate> This is a wrapper that that lets an old dtml file be replaced with a python function, without having to update all the old dtml files that call it. In other words, Internalized External Methods ;-) Why? Because Ive only just realized how error-prone non-trivial dtml can be.(and how ugly error-free dtml is) hth, 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] Soft links again
On Wed, 27 Sep 2000 09:06:18 -0400, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Also, there's currently a buglet in >acquisition that makes it so that you can only perform the actions on >the symlink which "anonymous" is allowed to do. Woooh! Someone else that agrees this is a bug in Acquisition. Full report and patch at http://classic.zope.org:8080/Collector/1066/view 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] mailing list 'noise'
On Fri, 29 Sep 2000 10:23:52 +0200, Rik Hoekstra <[EMAIL PROTECTED]> wrote: >Karl Anderson wrote: >> >> Ken Manheimer <[EMAIL PROTECTED]> writes: >> >> > > > I dont see this as a problem: You only create a new list when the >> > > > traffic for that proposal gets too great for zope-dev. Threading is >> > > > good enough before that point. >> > > >> > > Yes, but zope-dev has a relatively high traffic load... Why should you >> > > have to put up with all that 'noise' if you're only interested in posts >> > > for your comparatively small discussion? >> I read the >> 2-10 articles that I'm probably interested in, and miss the 95% which >> is almost always noise. > >The question is why you'd want to receive all this if you don't have to >(as remarked above). ...because it is usually a mistake to categorize any discussion as small, to exclude it from the mainstream zope-dev. I started this thread with a request that developers use zope-dev in the way requested by the Fishbowl Process document - but (I assume) it has also been valuable to people thinking about a next-generation wiki. That would not have happened if discussion was partitioned into Wikis (Todays wikis - not VaporWikiNG) unless some WikiNgWiki person was (by coincidence) keeping up with the FishbowlWiki. Are you really advocating that? >as long as you can follow it. But for prolonged and diverging >discussions? Not quite IMO/Experience. Can you explain why? >Or for discussions that you fall >into in the middle? Agreed - Todays Wikis are better than todays email list archives. >And what if you want to follow discussions at >different places, with different tools and you depend on a POP Server or >differential access (POP/IMAP/Web) to a mailserver? Its true that the web model is increasingly becoming a lowest common denominator. Are your suggesting that a majority of Zope developers actually need that? (Agreed, a VaporWikiNG that does both would be nice) >As I understood it, the discussion is less about tools and more about >modes of discussion. But we couldnt be having this discussion (in any mode) without tools. *My* email and news tools support the mode of discussion that we are advocating *better* than *Todays* Wikis 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] Re: CoreSessionTracking proposal
> > i.e. it is secure if the key *is* the data, rather than a key to the > > data. > > Can you explain? I do not see what you're getting at. Consider how the tree-tag stores its 'session' data. Its impossible to hijack a tree-tag session because the 'session' state is stored by the client (in the URL) in full. There are other differences between this type of session and the CoreSessionTrackingProposal; but the advantages are not all one 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 )
RE: [Zope-dev] Re: CoreSessionTracking proposal
> Are you suggesting that the session token should actually > store session > data? As an alternative SessionManager, it appears to have some advatanges that others do not. It is the only option (AFAIK) that avoids the session hijacking problem without relying on security-through-obscurity (the problem you mentioned, but its not one that gets me excited). Its also the only sensible option that lets you bookmark your place in a session, and return to it much later (which interests me more). > Or are you just pointing out the difference between the > implementation an implementation that meets the requirements > of sessions > and an implementation adequate for things like the tree tag? Isnt the tree tag an example of one Session use case? It smells alot like a session to me. ___ 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] Re: CoreSessionTracking proposal
Chris Wrote: > yeah, but have you ever tried to have two copies of a tree open on the > same data? That problem wouldnt arise if the page containing the tree tag used a URLDataSessionManager ;-) A different Chris Wrote: > Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs > much from not keeping session-related data in the token. I guess you could > argue that a session token that holds application data is "more random" due > to the nature of its composition, and due to that it can't be "guessed" as > easily (I doubt anyone would even try). One of the purposes of the random > element of the session token in the current implementation is to address > this "token guessing" risk. Agreed. With a large session-key the guessing game is hard. When storing session data in the URL it is theoretically impossible. Some people might find this appealing. (not me) > But all of these ponderings are kind of moot, because session > data can be > arbitrarily large (session data on the order of a megabyte > will probably not > be uncommon), so the data can't realistically be embedded in the token > anyway. Agreed, in-URL session data is not a universal solution. Im definitely only interested in implementing this as an *alternative* SessionManager, and I am aware of these limitations. > > Its also the only sensible option that lets you bookmark > your place in a > > session, and return to it much later (which interests me more). > > I don't understand what you mean... a session token that > doesn't include > application data has the same property. That's essentially > its reason for > being around at all. (If you're concerned that the session > token isn't > URL-compatible, it is... the current implementation lets the > session token > be transferred via a query string, inlined URL elements, or > as a cookie > value). Parts of the token *never* expire, so you can > happily bookmark > something with a token value embedded (or receive and > continue to resend a > persistent cookie). What about the scenario 1. I have a half full shopping cart (or a half opened tree tag) 2. I bookmark that half full cart. 3. I fill up the cart, but then change my mind. 4. I return to the bookmarked page - do I go to A. the half full cart from step 2, or B. the full cart from step 3? 5. I return to the bookmarked page 12 months later - do I go to C. the half full cart from step 2, or D. the full cart from step 3, or E. an empty cart, because the session cache had been purged. I guess B D and E all make sense in the context of a shopping cart (feel free to disagree; Im not too hot on shopping cart usability) I'm currently using a fremework built around in-url data to maintain the state of a sophisticated View (as in an M-V-C idiom). Options A and C are essential, since users need the ability to bookmark a view and return to it later. However most views are transient, just intermediate views on the way to the view that they want to keep. I dont have the storage on the server to indefinitely record every view that has ever been seen, however the server has no way of knowing which views have been bookmarked. The only option is to store all view state on the client, inside the bookmarked url. Being able to use a SessionManager to integrate a (rewritten) tree tag into my rich views is appealing. ___ 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-ZEO] How to get rid of the cPickle and asyncore dependency hasslesncy hassles
[cc to zope-dev.] > > Ive been using Zope only with Python 2.0 recently. > > That's great to hear. I'm frankly a bit surprised that > this works. 2.0 is a suprisingly conservative upgrade from 1.5.2 > Did you have to make many changes to Zope? All my critical patches are already merged into the Zope cvs, or the Python cvs ;-) There are also some non-critical bug fixes related to Unicode awareness, bundled up with my other Unicode-In-Zope patches at http://www.zope.org/Members/htrd/wstring. These mostly relate to the fact that Zope does not defend against objects that raise exceptions when converted to a string using str() - and Unicode objects do this frequently. (At the moment these extra patches are not 1.5.2 compatible... Ill work on this if DC feel the need for a transition period during which Zope supports both 1.5.2 and 2.0.) > I heard that ExtensionClass didn't work with Python 2.0. It looks like a little work is needed to support 2.0's garbage collection of cyclic trash - but thats not enabled by default. Apart from that, everything works very well. (In some ways, better than 1.5.2) ___ 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-ZEO] How to get rid of the cPickle and asyncore depende ncy hassles
On Fri, 6 Oct 2000 15:06:59 +0100 , Toby Dickenson <[EMAIL PROTECTED]> wrote: >All my critical patches are already merged into the Zope cvs Arh no - I lied. http://classic.zope.org:8080/Collector/1442/view is still outstanding. Not strictly a 2.0 bug; it applies to 1.5.2 too, but the Py_TRACE_REFS debugging option is more likely to be turned on by default in 2.0 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] Re: Python 2.0; Garbage Collection
[Toby] > It looks like a little work is needed to support 2.0's garbage collection of > cyclic trash [Neil] > Which 2.0 are you using? I was basing my comments on my last attempt in mid July. Ive just tried enabling WITH_CYCLE_GC again (and with the patch below) and it does all seem to be working happily. Ill make further tests next week. Index: z2.py === RCS file: /home/cvs/development/external/Zope2/z2.py,v retrieving revision 1.4 retrieving revision 1.7 diff -c -4 -r1.4 -r1.7 *** *** 430,443 if v=='-': v='' DNS_IP=v elif o=='-u': UID=v elif o=='-D': os.environ['Z_DEBUG_MODE']='1' DEBUG=1 elif o=='-S': sys.ZMANAGED=1 elif o=='-X': --- 429,448 if v=='-': v='' DNS_IP=v elif o=='-u': UID=v elif o=='-D': + try: + import gc + except ImportError: + pass + else: + gc.set_debug(gc.DEBUG_LEAK) os.environ['Z_DEBUG_MODE']='1' DEBUG=1 elif o=='-S': sys.ZMANAGED=1 elif o=='-X': 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] Building Zope on Linux
On Wed, 11 Oct 2000 07:57:52 +0800, "Sin Hang Kin" <[EMAIL PROTECTED]> wrote: >Recently I report the MyMath.h is missing. After receiving the help from the >list, I realize I have just got the python 2.0 beta from the sourceforge >cvs. the file must have been removed from python. > >Are there any branch of Zope which is intended to run on Python2? I would >like to propose a new branch for python 2 support on the cvs. You dont need to use Zope's own version of cPickle and cStringIO with Python 2.0 - the versions supplied with Python are newer. (Zope included these special versions because 1.5.2 was not new enough) 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] SessionManager, BerkeleyDB, and license compatability
I understand from the SessionTracking wiki that this product may use BerkeleyDB http://www.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/CurrentStatus The BerkeleyDB license at http://www.sleepycat.com/licensing.html indicates that it may only be distributed free of charge with software that is 'freely available and redistributable by others'. We are currently using Zope to develop an application that does not fall into this category. It would be a serious problem for us if Zope's core had a dependency on code with this type of license. 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] Xron fragility
>Yes, using Client.py was the easiest way to do that. The biggest problem >with Client.py is its dependency on HTTP. If your server is set up to >only accept HTTPS, then you can't use Xron -- not a desirable trade-off. If security is the problem, you could configure the HTTP part to listen only on a loopback interface. (yes, this is supported on NT and windows 95 too) >We need another mechanism that achieves the same goal -- simulating the >environment of a request -- without going all the way back to the >socket. I always thought the use of Client was very elegent. The performance hit is negligible, and all the plausible alternatives need many more lines of code. Another advantage is that it promotes testability of the scheduled events since it is easy (trivial) to reproduce the environment in which they run when scheduled. 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] More almost __call__ ;-)
On Fri, 13 Oct 2000 11:48:39 +0100, Chris Withers <[EMAIL PROTECTED]>
wrote:
>I have a Python Product Class, with a method, a_method, that gets called
>from some of the Python Product's management screens (encapsulation is
>good ;-)
>
>This method needs several parameters from the namespace, so when it's
>called I was hoping I wouldn't have to do something nasty and clunky
>like:
>
>
>
>Given my recently acquired __call__ Zen, I thought 'No problem...' and
>tried to define the method as follows:
>
>isDocTemplate = 1
>
>def a_method(self, ignored=None, md=None):
>
>...with the hope I'd just be able to do and pluck
>the stuff from md.
>
>No dice.
>
>md and ignored turn up as None from all the calls.
>:-(
>
>What am I doing wrong? How can I get access to the namespace in a method
>of a class like this?
You need to have the isDocTemplate=1 as an attribute of the method
object itself, not the class that contains the method.
You also need some extra voodoo if you want to call the method
directly from ZPublisher (by including the method name in a url). Here
a link to a wrapper that does it all
<http://www.zope.org/Members/htrd/howto/FunctionTemplate>
you would use
def a_method(self,md):
do_stuff_with(md['param1'],md['param2'])
a_method = FunctionTemplate(a_method)
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] More almost __call__ ;-)
> That looks like it'll do the trick... I wonder if there's any way you > can role it up into a Product so that I don't need to have > FunctionTemplate.py in each folder of a product that needs to use it? Im working on a set of tools to aid my transition to a dtml-free Zope. Eventually I will package them all as a whole. ___ 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] More almost __call__ ;-)
> Is it *really* the case that you often want to method to be > called directly > via the Web *and* and from DTML? This doesn't seem right to me. Im suprised that you are suprised. Consider a method called 'summary' that returns a plain-text summary of an object. Thats useful to call from DTML (maybe assembling a summary of several objects), via xmlrpc, and directly from ZPublisher (by browsing to the url of the method). Maybe this 'summary' method lets you pass some parameters to control the level of detail of this summary. These requirements are probably best satisfied using a plain python method, which uses plain python parameters. So why use the dtml namespace at? The only good reason is if the method was *previously* implemented in DTML (it seemed a good idea at the time) and you want to replace it with python without having to change all the dtml that uses it. ___ 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 )
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):
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] 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 )
[Zope-dev] RE: Security requires Acquisition?!
> Okay, this did the trick, but I'm not very happy with the result :-( > > I don't want the DisplayClass to be acquiring and I don't really see > (from a moral standpoint ;-) why I should need to mix in an Acquisiton > class to make security work :-S I suspect that was a rhetorical question, but ill answer anyway. Zope security is context based: Users can be defined in a subfolder and only have access under that folder, they can also be given local roles for a given folder. The role:permission mapping is set per-folder. Any security aware object needs to know its context. > That said, I think Shane said that Zope security is > predicated a lot on > Acquisition. Now, can I get the solution I'm looking for by mixing in > Aquisition.Explicit, still have the security stuff work and > not have the > DisplayClass acquiring attributes I don't want it do? Yes, you will need to set Acquisition.Acquired for the necessary attributes. Alternatively there may be other ways of avoiding an object using some specific acquired attributes: I often define an index_html=None to avoid a class using its container's default view. Wanting to make an object non-acquiring may be a danger-sign of some other problems. If the correctness of your program depends on the absence of certain attributes (acquired or otherwise) then you need to take extra care over PropertyManager-like features, which might allow a user to add the critical attribute. hth, ___ 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] Unique and Contant object IDs
On 24 Oct 2000 15:14:24 GMT, [EMAIL PROTECTED] (Ty Sarna) wrote: >Unfortunately there are a lot of things that Zope just can't do because >there is no way to get a persistent "ticket" for an object that can be >handed out to some external system, and then later redeemed for the >(properly wrapped) object. Pathnames are not useful, because they don't >last for the object's lifetime. How come? because you want the identity to remain unchanged even after the object is moved? or duplicated? 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] Migrating from ZClasses to Python Products
On Tue, 24 Oct 2000 20:16:30 GMT, "Jason Spisak" <[EMAIL PROTECTED]> wrote: >I am trying to address shortcomings like not having a >"dictionary" type property in Zope properties, etc. Aha! in that case you dont really need to convert from ZClass to python class; you only need to modify your existing ZClass so that it has an extra python base class. * No need to trawl through your database to convert each instance * No need to rewrite the bits that work well as a ZClass You can do this using the method _setBasesHoldOnToYourButts defined in ZClass.py, and you may be able to find some instructions in the list archives. (Its often safer to create a special python base class for each new ZClass, even if that class is empty, just in case) 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] RE: Security and Acquisition?!
> Anyone know what those attributes are?
Heres a good trick: add this method to your class to see which attributes it
is asked for, but doesnt implement.
def __getattr__(self,id,reg={}):
if not reg.has_key(id):
print `id`
reg[id]=id
raise AttributeError(id)
> But these are very specific classes that exist for no longer than the
> duration of serving a single page request, and it'd just be
> nice to know
> that they're not going to acquire and fluff they shouldn't...
An alternative approach: apply tighter security to the method that
constructs these objects, and leave the objects themselves completely open.
___
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] Large file support
On Tue, 24 Oct 2000 20:31:52 +0200, [EMAIL PROTECTED] wrote: > If the Zope object knows how to produce the data themselves, they > could push producer(s) directly to the channel. I added a single > check in ZServer.HTTPResponse(256) where a temporary file is only > created if the data is larger than the in-memory buffer *and* > doesn't already look like a producer with 'more' as a method. Wahay! thats been on my todo list for ages. Ill take a look when I get some time. 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] Unique and Contant object IDs
> Yeah, I'd love an ID I could use to grab an object no matter how often > it was used. I suspect you will have to build this yourself. Store a sufficiently random id inside your objects when they are created, and use a ZCatalog to index them. > Why wouldn't the following work though: > > ...in a class method... > > self.theobject = theObject > > ...where theObject is something I want a reference to and self is a > persistent class... theObject would need to be persistent too. This has a number of characteristics that I would class as problems, but may be exactly what you want: * theObject will have different acquisuition context when accessed through its main path, and through self.theobject. This means different: * security * absolute_url * configuration obtained through acquisition. What if theObject is CatalogAware? * theObject isnt removed from the database when it is deleted from its folder; this other reference keeps it alive. ___ 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] Large file support
On Wed, 25 Oct 2000 12:35:23 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: >How does this differ from Local FS? I dont recall exactly how LocalFS worked, but without this patch it basically had three options for handling its output: 1. copy the whole file into memory before sending the first byte. (this is ZPublishers normal publishing of a functions return value) 2. copy the whole file into memory a chunk at a time, and start sending the first chunk as soon as it is available. (this is normal RESPONSE.write) 3. copy the whole file into a temporary file a chunk at a time, as soon as the first chunk is available read it back and send it. (this is RESPONSE.write after a Content-Length header has been set, as used by File objects) >> Working with files > 20MB I notices some serious performance/scalability >> issues and investigated. Mmmm 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] Large file support
> I should also note that if you create a producer, you will have to > override the __len__ method to return the entire length of the data. > > This is because RESPONSE.write doesn't allow you to set the > length of a > write and there code during output that checks the size of the written > object. > > Wahay! thats been on my todo list for ages. Ill take a look > when I get > > some time. Damn. Its back on my to-do list then ;-) ___ 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] Bindings and Votings
> ...but can you bind self to the context or, more perversely, > context to > the container? As the first line in your PythonMethod: self,context = context,self But why would you want to? ___ 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 memory error on Windows NT
On Fri, 3 Nov 2000 09:44:42 +0100, "Coi Giovanni" <[EMAIL PROTECTED]> wrote: >someone has never seen this kind of error on Windows NT >4.0 (last patch update) while executing IIS 4.0 + Zope 2.2.2? >The panel say: > >python.exe >The instruction at "0x1b271a1f" >referenced memory at "0x" >The memory could not be "read" That sounds like a bug in an extension module (or a hardware fault, unless you have other software on this machine that doesnt have any problems). Are you using any unusal extension modules? >it hang python (and so Zope) until someone, looking at the server >console, notice the panel, and click the (only) OK button. Yes, thats a PITA. Have a look at Microsoft's Knowledge Base article Q188296 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] cPickle.c
On Fri, 3 Nov 2000 13:03:50 +, Robin Becker <[EMAIL PROTECTED]> wrote: >I see a reference to mymath.h in in cPickle.c is that intentional? With python 2.0 you dont need (and shouldnt use) the cPickle or cStringIO that comes with Zope 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] python memory error on Windows NT
> > That sounds like a bug in an extension module > The installed packages on the site are (all the Zope 2.2.2 > released with > and): >ZODBCDA (Installed product ZODBCDA) > we use 2 ODBC connection on 2 MSAccess MDB and no python > extension. > I do not know where and when the problem happens. But it happens. I suspect Access ___ 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] Adding properties in __init__
On Tue, 07 Nov 2000 11:54:57 +, Chris Withers <[EMAIL PROTECTED]>
wrote:
>I have a product class that subclasses SimpleItem and PropertyManager.
>
>If I try and add a property in __init__ as so:
>
>self.manage_addProperty('AProperty','1\n2\n3','lines')
>
>I get the following wonderful error:
>
>Error Type: AttributeError
>Error Value: aq_base
>
>I'm guessing that this is because self isn't an acquisition wrapper in
>__init__ (even though SimpleItem is Acquisition.Implicit) but what am I
>supposed to do to add a property in __init__?
__init__ has no idea of context, so its less useful in Zope than you
might usually expect.
Your object must have a factory method somewhere I suggest adding
an extra method to your object (I always name it '_after_create') and
arrange for it to be called by your factory once the new object is
installed in its container.
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] Cache parameters
On Wed, 8 Nov 2000 11:37:51 -0800, "Andy McKay" <[EMAIL PROTECTED]> wrote: >Just wondering what kind of cache parameters people run on their Zope >installation. > >It would seem running a high target size and maximum time between accesses >would speed up those requests it can find the cache, but not cached request >take longer since more RAM is used in the maintaining of the cache (guess). > >Has anyone found a sweet spot away from the standard, I guess of course it >all depends on the individual Zope site, this one is particulary ZCatalog >heavy. Or should I just leave it at the default, which I found seems to work >fine. If you are in the mood for experimenting, you might like to try reducing the number of publisher threads. Each thread gets a separate copy of the ZODB object cache, which accounts for a large chunk of Zope's memory usage. You might find that this lets you use a larger cache - with an overall gain in performance. 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] Re: New Name for Python Methods
On Thu, 09 Nov 2000 10:18:47 -0500, Shane Hathaway <[EMAIL PROTECTED]> wrote: >Here's what the meat of the problem really is, explained well by Jim: > > Evan's Zope objects named "Python Methods" don't behave > or look like methods defined by the Python programming > language. There are quite a few people who think this is a > problem. They dont behave exactly the same, but Ive not seen a good summary of what differences those people believe to be a problem. Does anyone have a pointer? I can see many differences, but none I would class as a problem. (On the other hand, Im not adverse to using bytecodehacks in my straight python projects too. Perhaps Im just working with a broader definition of 'method') 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] Splitter
On Fri, 10 Nov 2000 07:50:21 +0800, "Sin Hang Kin" <[EMAIL PROTECTED]> wrote: >(may be turning zope >completely a unicode app). I have patches to give Zope good unicode support (good enough for me ;-) at http://www.zope.org/Members/htrd/wstring No TextIndex support yet though; feel free to contribute some. 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] License issues
On Tue, 14 Nov 2000 09:48:20 +0100 (MET), [EMAIL PROTECTED] (Juan David Ibáñez Palomar) wrote: > it's illegal to distribute GPL code together >with [ZPL] code I dont see this as an issue for Zope (taken as a whole). There is no problem with other developers releasing GPL products for Zope, as long as they do not create a combined distribution of Zope+TheirProduct. Separate rpms is enough. I agree that GPL-compatability would be better for some of Zope's components which are useful outside of Zope (ZPublisher, ZODB, ZEO, etc) On Wed, 15 Nov 2000 16:09:40 -0600, Jimmie Houchin <[EMAIL PROTECTED]> wrote: >The GPL would protect DC from predatory competitors. It would also allow >for Zope's adoption in certain environments. I also believe some people >would relicense their products to the GPL if it were Zope's native >license. If a future version of Zope was released under GPL, I (and I guess many others) would *need* to create a fork from the last non-GPL version. This is to nobodys benefit. 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] Two glaring omissions
On Tue, 14 Nov 2000 15:39:59 -0500, Shane Hathaway <[EMAIL PROTECTED]> wrote: >> 2. The ability to rename properties after instances of the classes have >>been created (and have the data in those fields preserved) > >This is also more difficult than it sounds. You'd have to either scan >through the entire ZODB and modify class instances or associate >properties with a magical, unchanging ID. The latter solution is dead >wrong, but the first is actually kind of interesting. If there were a >separate index for each object type in the ZODB, it would be possible. >In fact, when ZODB is running from a relational database, there is >indeed a way to do that. Hmmm... Or if your ZClass has a python base class, then a __setstate__ method could be added to do the same thing incrementally. Like all changes to a Python base class, this requires restarting the server. 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] Two glaring omissions
On Thu, 16 Nov 2000 19:51:24 -0500, Tres Seaver <[EMAIL PROTECTED]> wrote: >Toby Dickenson <[EMAIL PROTECTED]> wrote: > >> On Tue, 14 Nov 2000 15:39:59 -0500, Shane Hathaway >> <[EMAIL PROTECTED]> wrote: >> >> >> 2. The ability to rename properties after instances of the classes have >> >>been created (and have the data in those fields preserved) >> > >> >This is also more difficult than it sounds. You'd have to either scan >> >through the entire ZODB and modify class instances or associate >> >properties with a magical, unchanging ID. The latter solution is dead >> >wrong, but the first is actually kind of interesting. If there were a >> >separate index for each object type in the ZODB, it would be possible. >> >In fact, when ZODB is running from a relational database, there is >> >indeed a way to do that. Hmmm... >> >> Or if your ZClass has a python base class, then a __setstate__ method >> could be added to do the same thing incrementally. Like all changes to >> a Python base class, this requires restarting the server. > >Correct in theory, but broken in practice: if you make your ZClass >persistent (i.e., you leave checked the "Include standard Zope >persistent object base classes?" checkbox on the "Add ZClass form), >then Persistent will be the first base class in the list, and *your* >'__setstate__' will never be called! Some more theory thats not backed up by any practical experience in this area: Would it be sufficent to create a base class that derives from Persistent and then uncheck the box? or does that checkbox get involved in some other magic? 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] Conflict Errors
On Tue, 21 Nov 2000 17:03:17 +, Chris Withers <[EMAIL PROTECTED]> wrote: >> It happens when more than one thread tries to modify the same object in >> storage at the same time. It's Zope's equivalent of record-locking... It's >> normal. There's no corruption or anything, it's telling you that it avoided >> a write that might have caused problems. Zope tries three times to retry >> the write. If the object is still locked by another database connection >> after three writes, it propogates the exception up to the app level. That's >> the error you see. > >Hurm, well, it appears to happen when we're doing a lot of sequential >write to a product (automated bulk data upload), but the thing that >triggers it off is actually trying to read a page from the same area of >the site... confusing. Although that could also be a one-off >coincidence... ZODB marks each persistent object that is modified during a transaction. Before committing, it checks whether any of those objects have been modified-and-commited in another transaction. If it has, it raises a ConflictError. If your 'page read' really doesnt modify any objects (check your undo log, or use tranalyzer) then it cant cause a ConflictError. >You say no corruption or anything, but if a submit results in that >error, does the submitted form data get processed or not? As Chris explianed, the publisher will retry up to three ConflictErrors. If you see this message only in a log then it probably suceeded on one of those retries. If you see it in a traceback returned over http then the transaction has been aborted. No corruption, however your request has not been processed. >> Careful application coding can reduce the chance of conflict errors. > >Can you describe what you mean by careful application coding? "Minimise the chance of a single persistent object being modified by two concurrent transactions." Some examples: 1. The much-maligned ZODB-page-hit-counter is bad in this respect. Each 'read' of a page modifies the counter object, causing the second concurrent read (which is actually a write) to raise ConflictError. 2. Folder objects are pretty good, although you cant concurrently add two objects to a folder since both transactions modify the folder object. 3. If you need something folderlike with a higher hit rate, it is possible to avoid some conflicts by splitting the folder. For example, having one sub-folder for each initial letter of the id. You can add objects 'chrisw' and 'tdickenson' concurrently (into subfolders with the id 'c' and 't'), however concurrently adding 'chrisw' and 'chrism' would cause one ConflictErrorm because they both modify the sub-folder 'c'. (BTreeFolders have the same advantage, for the same reason, only neater) 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] debugging authentication problems
Im have trouble tracking down why one specific method is needing authentication. Can anyone suggest any tips or tools? 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] debugging authentication problems
On Mon, 04 Dec 2000 09:38:10 +, Chris Withers <[EMAIL PROTECTED]> wrote: >Toby Dickenson wrote: >> >> Im have trouble tracking down why one specific method is needing >> authentication. Can anyone suggest any tips or tools? >> >> Toby Dickenson >> [EMAIL PROTECTED] > >Shane's ZDebug tool can help, but where people have helpfully raised >Unauthorized as a string exception, it doesn't seem to kick in. > >If anyone's got any other tips, I'd love to hear them too :-) Now Ive found the problem, I dont think anything less than pdb would have helped. Thanks for the tips, 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] case insensitive sorts
On Wed, 06 Dec 2000 18:00:31 +, Chris Withers <[EMAIL PROTECTED]> wrote: >(reasons of course would be helpful, particularly if you want it to stay >like it is ;-) I noticed the smiley, so Im not sure how serious the suggestion is. Ill bite anyway: 1. Python doesnt distinguish between 8-bit-strings and byte arrays. (for example, ZODB uses 8-byte-long 'strings' as oids). Do you want a casewise sort for byte arrays too? 2. 'sort' uses 'cmp'; so effectively you are asking for string's cmp to be case insensitve. Can you demonstrate a case-sensitive collation function that is as simple as your case-insensitive one: >def _default_sort(x,y): >return cmp(string.lower(x),string.lower(y)) 3. ZCatalog stores objects in a pre-sorted order. Changing the sort order of any object (not just strings) would break *all* existing ZCatalog instances that store mixed case strings. (and other applications too - the python language reference documents that this assmption is safe at least until python3k) 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] case insensitive sorts
On Thu, 07 Dec 2000 10:54:06 -0500, Shane Hathaway <[EMAIL PROTECTED]> wrote: >The one thing I wonder is whether the sort order is consistent between >different versions of Python. I actually have a Collector bug report on exactly this question. http://classic.zope.org:8080/Collector/1219/view (Status: pending. and has been for 8 months :-( In reality, I think it is only a theoretical problem. The current implementation takes much more care than it is required to by the language reference. Indeed, extra effort was taken in Python 2.0's implementation of Unicode. 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] Turning acquisition off selectively.
On Fri, 08 Dec 2000 10:57:48 -0500, Jim Fulton <[EMAIL PROTECTED]> wrote: >I'm inclined to think that in some future version of Zope, we >should switch to making explicit acquisition the norm. Jim, do you have any opinions on some of the other acquisition strategies that have been mentioned on the list? In particular, there seems to be merit in an acquisition that searches only the containment heirarchy. 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] python 2.0, windows and zope
On Wed, 13 Dec 2000 11:33:12 -0800, "Andy McKay" <[EMAIL PROTECTED]> wrote: >I think thats just the fella I need! Thanks... >Will let you know progress The current CVS of Zope, as of yesterday, includes some tricks to use a different Setup file between 1.5.2 and 2.0... the essential difference is that you must not use zope's version of cPickle and cStringIO with python 2.0. Ive been running Zope (on NT, 95, and linux) with the current CVS of python since its unicode support was first added. There are some patches in the collector if you want to use a debug build of python, but basically that snippet from Brian is all you need. There are some other minor bugs that means its not quite up to production use yet. Im currently working on getting those fixed for the next release of Zope: you might want to look at http://dev.zope.org/Wikis/DevSite/Projects/Python20Migration/FrontPage I hope this helps, 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] RE: objectIds accessiblilty & and a proposal
On Mon, 18 Dec 2000 14:11:51 -0500, "Brian Lloyd" <[EMAIL PROTECTED]> wrote: >This is something that has come up before. I propose >that the real problem here is that 'objectIds' should >not be web-traversable. > >I have, in fact, proposed this before. It caused a bit >of grumbling among people using xml-rpc, who were using >objectIds remotely, so we never came to closure on it. Please No. Zope security is complex enough without having to worry about different security settings depending on how a method is accessed. (And we should have a lower tolerance for complexity when it applies to security) If a user has permission to access a method then he should be able to access it any way (xmlrpc, ZPublisher, DTML, PythonMethods) Conversely, if a user is given an "Access Denied" message using one means of access (say, using ZPublisher) then he *must* also be denied using every other one. Security testing is much harder without this property. If anyone is seriously worried about this a a problem then can already deny Anonymous users the 'Access contents information' permission, and grant a proxy role to methods that generate indexes. (Indeed, this may make sense as the default configuration) 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] RE: objectIds accessiblilty & and a proposal
> -Original Message- > From: Dieter Maurer [mailto:[EMAIL PROTECTED]] > Toby Dickenson writes: > > > ... protocol specific access rights ... > > Please No. > > > > Zope security is complex enough without having to worry about > > different security settings depending on how a method is accessed. > > (And we should have a lower tolerance for complexity when > it applies > > to security) > > > > If a user has permission to access a method then he should > be able to > > access it any way (xmlrpc, ZPublisher, DTML, PythonMethods) > I agree with you mostly. > >But it might be a significant difference, whether >you access via HTTP or HTTPS or even a protocol that >provides trusted authentication. As a matter of principal, authentication issues do not belong in the permissions machinery, but rather in the User machinery. As a matter of practicality, changing the user machinery is also the smallest change that achieves what you want. What if it was possible to specify per-user the level of security required (Basic is ok for some users, another needs https, etc). You could do this today with a custom user folder, but it might make sense to add it to the standard one. Your very-private-method could then be protected by a permission that is only given to users who are configured to require https. This obviously works for normal users, but it applies to anonymous users too The word 'zen' hasnt been used on the list for a while, so ill drop it in here Zope has a standard "Anonymous" user who represents users who do not authenticate. This user has no management interface, and he has a fixed set of roles - this makes him very limited. However, you *dont* *need* *to* *use* *it*. Create your own substitute as a new user (I like to call him "Anon") in the root folder with a blank password. This is useful if you create a product with a feature that you want to make available anonymously today, but may want to authenticate in the future. You could tweak the permissions mapping so that the appropriate permissions are given to the "Anonymous" role, however that leads to alot of re-tweaking when you make the change. A better solution is to create a new role, and grant that role to "Anon". This step (granting special roles to the anonymous user) is the thing you cant do with the regular anonymous user. I hope this helps, ___ 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] ANNOUNCE: PartitionedFileStorage
On Tue, 02 Jan 2001 15:33:03 -0500, Shane Hathaway <[EMAIL PROTECTED]> wrote: >But like I told ChrisW, I think BerkeleyStorage will fill the need that >PartitionedFileStorage was only partitially addressing. FileStorage has fewer license compatability issues. Im not yet sure about the extent of any problems this may cause. 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] Frozen Zope?
On Wed, 3 Jan 2001 15:09:02 -0500, "BS" <[EMAIL PROTECTED]> wrote: >My goal is to create a very easy install of Zope that consists of one or two >files. For some of my clients this seems less intimidating on their machines >(they would rather not see the "source code", just an executable). On win32 there are several other options, depending on your users. You could hide the source directory, or use Explorer's Web View to give it a less intimidating appearance. I hope this helps, 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] Zope from CVS for Windows
On Sun, 07 Jan 2001 10:39:45 +, Steve Alexander <[EMAIL PROTECTED]> wrote: >Is anyone regularly building Zope from CVS for Windows? > >I want to try something out on a Zope 2.3 build on windows, but I don't >have easy access to windows development tools. I think you may be out of luck, unless you can get hold of Microsoft Visual Studio 6.0 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] SiteAccess and Catalog
Has anyone got a ZCatalog working with SiteAccess? Ive tried 2.2.0 through 2.2.5, and Im seeing that it is storing paths to objects that it cant later traverse. Any help greatly appreciated, 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] Mapping multiple IP addresses/domains to one Zope
On Wed, 24 Jan 2001 10:07:29 -0600, "Aaron Gillette" <[EMAIL PROTECTED]> wrote: >My company has many sites which share some content. Each site uses a >different IP address. I would like to bring all of these sites into one >instance of Zope on an NT machine. I am looking at the possibility of either >1) running Zope behind IIS, or 2) running Zserver exclusively. Is this server accessible to untrusted users? If yes, then go for IIS. ZServer on its own isnt sufficiently bullet-proof. > Personally, >I'd rather take the time in advance to learn how to do the whole thing in >Zope, as I envision switching to a Linux server in the near future, and I >believe that this would ease the migration. Yes, its safe to copy zope databases between platforms, and zope itself is very platform-neutral. >My question is this: How do I map different IP addresses/domains to >different Zope folders? I am pretty new to Python (but learning fast!), so >any snippets of sample code would be much obliged. Search on www.zope.org for SiteAccess. 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] Hard set port number in 2.3?
>Tim Ansell wrote: >> >> But now with zope 2.3.0 it keeps writing urls going to the firewall box >> on port 8080 instead of port 80 like it previously did. >> >> Anyone know how to fix this problem? Where i should look? Hmm. I hadnt been aware that VirtualHostMonster was coming in 2.3.0, so I developed something that fills much the same niche: fixing the urls when Zope runs behind a proxy, with less hassle than using SiteAccess. My offering isnt as flexible as VirtualHostMonster (but that might be one reason why it works, when v-h-m doesnt ;-) http://www.zope.org/Members/htrd/howto/host-server http://classic.zope.org:8080/Collector/1892/view 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] ThreadSafeCounter 0.0.1 released
On Mon, 12 Feb 2001 10:27:02 +0100, Martijn Pieters <[EMAIL PROTECTED]> wrote: >The ZODB will invalidate and force a retry on one of the connections. >Chris's code is threadsafe and will result in unique, sequential values. ** Unless a transaction gets retried for some other reason, when it will appear to skip a value. 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] Virtual Host Monster Paranoia
On Tue, 13 Feb 2001 10:24:54 +, Chris Withers <[EMAIL PROTECTED]> wrote: >I really like the idea of these things but I am concerned about something that >allows anonymous users to futz with traversal. > >Can someone put my fears to rest that using these won't let anonymous users do >bad things to my sites? I didnt realize V-H-M was coming in 2.3.0, and developed an alternative that fills a similar niche: http://www.zope.org/Members/htrd/howto/host-server This option has fewer 'moving parts' than anything based on SiteAccess (which I still feel uncomfortable with, sorry evan) 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] Virtual Host Monster Paranoia
On Tue, 13 Feb 2001 10:30:26 + (GMT), Matt Hamilton <[EMAIL PROTECTED]> wrote: >I use them in conjunction with Apache's mod_proxy to rewrite >http://www.simpledomain.com to the long >http://zopehost.foo.com/blah/blah/VirtualHostMonstser/blah/blah. The Zope >host is behind a firewall, so anonymouse users cannot get to it directly. No, but they can get to: http://www.simpledomain.com/blah/VirtualHost/bad.stuff/blah which gets rewritten to: http://zopehost.foo.com/VirtualHost/http/www.simpledomain/blah/VirtualHost/bad.stuff/blah Understanding its behaviour behaviour might be beyond the complexity threshold for a paranoid admin to be comfortable. 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] Virtual Host Monster Paranoia
> Then again, there's the advantage of having something > included as a standard part of Zope. Yes, thats true. I would like to see this being rolled into the standard zope (and there is a Collector entry saying that), although I think its unlikely given the 'competition' from VHM. Having said that, a big patch is worse than a small patch. And http://www.zope.org/Members/htrd/howto/host-server is a really tiny patch ;-) ___ 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] More ZCatalog Stuff.
On Sat, 24 Feb 2001 21:44:36 -0500, Christopher Petrilli <[EMAIL PROTECTED]> wrote: >Chris Withers [[EMAIL PROTECTED]] wrote: >> "Michael R. Bernstein" wrote: >> > >> > Hmm. this seems like there ought to be a checkbox next to >> > the 'Add Index' form field labeled 'index numbers?'. Or >> > maybe a 'Text and Numbers' index as an additional index >> > type. >> >> I like these ideas :-) > >One of the ideas that has been tossed around for almost a year (and >Jim and I both liked last we discussed it) was "drop-in" indexes. >These would be individually managed, and you would be able to control >the splitter more (which is what you're reffering to in this case. In >addition, you might even have more detailed control over the searching >behaviours... > >SMOC :-) If you are interested in a short-term hack, it is possible implement your own type of index and add it to an existing catalog, without having to modify any of the ZCatalog product. Ive used that to implement a variant of KeywordIndex that uses a get_keyword method (rather than getattr) 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] More ZCatalog Stuff.
On Mon, 26 Feb 2001 19:00:58 -0800, "Michael R. Bernstein" <[EMAIL PROTECTED]> wrote: >Toby Dickenson wrote: >> >> If you are interested in a short-term hack, it is possible implement >> your own type of index and add it to an existing catalog, without >> having to modify any of the ZCatalog product. > >Ok, how? Please keep in mind that I'm more of a designer and >integrator than a coder. Today it requires some development effort ZCatalogs are a zopeish wrapper around a zope-neutral catalog object, which is stored in the _catalog attribute. That leading underscore is a clue that you shouldnt be using it directly, however you need to in order to create a custom index. Liek I said, this is a hack. The main problem is that catalog (and hence ZCatalog) implements a factory interface where you specify the name of the index type (for example "TextIndex", and it creates the indexing objects. I use the function below to: 1. Use a catalogs factory interface to create a KeywordIndex, to allow it a chance to raise an exception if anything is wrong. 2. If nothing goes wrong then I assume it is safe to replace the standard KeywordIndex with my custom subclass of a KeywordIndex. def ensure_question_is_indexed(self,question): question = unicode(question) cat = self.storage.timeseries_catalog index = UnTrackingIndex(question) if index.id not in cat.indexes(): # Add and remove a keyword index using # the published interface, # to allow the catalog a chance to complain. cat._catalog.addIndex(index.id,'KeywordIndex') cat._catalog.delIndex(index.id) # Use the private interface to do the real work cat._catalog.indexes[index.id] = index cat._catalog._p_changed = 1 You will need to implement a subclass derived from one of the standard indexes to provide your custom indexing policy, whatever that is. 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] More ZCatalog Stuff.
> I am assuming that the code you provided goes into a
> manage_addCustomIndex method that is part of a CustomIndex
> Python Product.
hehehehe, nothing so general-purpose as that ;-)
> > You will need to implement a subclass derived from one of
> the standard
> > indexes to provide your custom indexing policy, whatever that is.
>
> Can you provide the code for your custom KeywordIndex, so I
> have a starting point? I realize yours subclasses a
> KeywordIndex, and I probably need to subclass a TextIndex,
> but it would still probably help. I can integrate and hack
> on other peoples code better than I can write my own from
> scratch.
from SearchIndex.UnKeywordIndex import UnKeywordIndex, MV, intSet
from types import ListType, TupleType
class UnTrackingIndex(UnKeywordIndex):
meta_type = 'Tracking Properties Index'
"""Like a Keyword Index, only it indexes tracking properties
"""
def __init__(self,question):
id = 'tracking_'+unicode(question).encode('unicode-escape')
self.question = question
UnKeywordIndex.__init__(self,id)
def index_object(self, i, obj, threshold=None):
""" index an object 'obj' with integer id 'i'"""
index = self._index
unindex = self._unindex
try:
kws = obj.tracking_answers(self.question)
if type(kws) not in [type([]),type(())]:
raise ValueError('Indexing a tracking property set of
inappropriate type %r' % type(kws))
except:
kws = (MV,)
# index each item in the sequence
for kw in kws:
set = index.get(kw)
if set is None:
index[kw] = set = intSet()
set.insert(i)
unindex[i] = tuple(kws)
self._index = index
self._unindex = unindex
return 1
___
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 )
