Re: [Zope3-Users] breadcumbs in new skin
Hi Lorenzo, Viewlets are a very nice tool when building skins. Try using the boston layer instead of the rotterdam layer and look through the implementation of viewlets in zope.app.boston. A breadcrumb viewlet is part of Tiks (www.tiks.org). Best regards, Darryl Cousins On Mon, 2006-02-13 at 16:57 +0100, Lorenzo Gil Sanchez wrote: Hi, I'm working on a new skin and I want to use the breadcumbs functionality in it. I have just one layer and the skin is defined like this: layer name=mylayer / skin name=myskin layers=mylayer rotterdam default / Inside my template.pt I have tried to use the macro breadcumbs without luck: span metal:use-macro=breadcrumbs / This macro is defined in the template.pt file of the Rotterdam skin but I don't know how to use it. Best Regards Lorenzo Gil ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users -- Darryl Cousins Tree Fern Web Services (NZ) Ltd 106 Sandes St Thames 2801 New Zealand +64 7 868 3139 [EMAIL PROTECTED] http://www.treefernwebservices.co.nz/ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Squid/Apache Caching
Steve Wedig wrote: I'm in the planning stages for developing a Zope 3 application. It would be nice to know my http caching plan ahead of time. It seems that the two main options are squid and apache. I was wondering if the most flexible setup might be to have apache running behind squid, and zope behind apache. My personal preference is apache - squid - zope But that's 'cos I like Apache's rewriting and have more faith in it as a front-end proxy for sanitizing requests and the like... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] RE: Zope3 Developers Handbook
Stuart, I apologize, but I haven't had time to look at workflow to see what breaks with 3.2... afaik, 3.1 worked, inasmuch as the tests worked and I didn't have any problems installing/using it... just out of curiosity, do you have a process definition already defined before you attempt to create the process instance? baldtrol ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] ZCML debugger?
On Monday 13 February 2006 17:06, Roman Susi wrote: If I compare this situation to Python, it is always quite straightforward to look at the source of the module or to help(thesamemodule) to see that I need first make an instance of some class and then use its methods. So, probably, Zope3 needs a kind of a tour which explains those links which are not explicitely visible. Python is a programming language with some libraries not a framework. The big challenge of a framework is to be pluggable. So Zope 3 is ultra-pluggable. The downside that arises is that you cannot document a set of features in a straight-forward manner. And again, you cannot expect to understand a framework from API documentation. This is even true for Python; if you want to understand on what's really going on, you have to read some real documentation. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Authentication, Principals and PAU...
On Feb 13, 2006, at 6:17 PM, luis wrote: hi all, I'm trying to get started with zope3, and while I think I'm beginning to understand parts of it, I'm still having a hard time with other parts, so I hope someone here can help me out a bit. my first questions are concerning authentication/ users / pau... as a learning-excercise i want to create an example app, where users can register themselves, login and upload files. I added one PAU to my site which uses session credentials and a principalfolder.. so now I can create users in that folder and can log into the system. that works, but when I tried to add additional information (mail, etc) using the principal annotation utility, it just doesnt work... There are many ways to add annotations for a user. If you already have a principal object, and your zcml has included the principalannotation package (as I expect Zope 3 does by default), then you can just say from zope.app.annotation.interfaces import IAnnotations annotations = IAnnotations(principal) annotations['my.package.name'] = 'whatever' # or a btree or whatever Lots of other ways to do it, but that's one. I created the interface and class to store the data, and tried to register them with a zmcl adapter and browser:editform for=zope.security.interfaces.IPrincipal, but nothing happened... so far I've been able to trace it down, the objects in the principalfolder do not implement IPrincipal, but only IInternalPrincipal, so my mapping in zcml is not active for my users. I'm not clear what you want to do here. to be honest, the difference between principals, internalprincipals and principalinfos is not that clear to me. IPrincipals are the primary security interface for principals. The others I expect (without bothering to look at the code) are implementation specific for a given authentication utility. With the pau, principals objects are generated as needed, on the fly, and not persisted themselves. I then downloaded schooltool to have a look how they implemented users there, and they don't use the pau at all, but created an own authentication utility. and they don't use the principal annotation util either, but store the person details as annotations on the objects themsleves.. That's one of the wonders of Zope 3: don't want to use implementation X of interface A? Write your own implementation Y for interface A and register it instead. As long as it complies with the interface, the intent, and the reality whenever I've tried it, is that you should be good to go. I don't know schooltool's history. There could be many reasons for them rolling their own. ...so...is this the recomented way of doing things? is the pau only meant to be an example auth-utility and applications are supposed to implement their own auth. mechanism? or maybe use the pau as a basic framework, but implement your own principalfolder as a pau-plugin? The pau is a basic framework, with a number of reasonable basic implementations. Plugins, such as the LDAP plugin in the svn.zope.org repository, can add capabilities to the pau. something else i noticed, is that in the pau the principalfolder lives inside the pau itself (the pau acts as a container) in software space (++etc++site), while in schooltool the users live in the persons folder in content space. is there a difference between software and content space for this?, specially in regard to users being able to register on their own, user-search or something else that can only be done in content- space but not in software/configuration-space or viceversa? It's a design decision. We have provided views in content space that manipulated objects actually over in ++etc++site. Also, since many pau plugins are utilities, when Jim's 'put utilities anywhere' proposal comes in you could in theory do precisely what schooltool did with a principals folder in content space but the auth utility still in ++etc++ Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] newbie design questions for UI to external data
On Feb 13, 2006, at 10:33 PM, Shaun Cutts wrote: Um... I guess I must have asked too many questions at once :) :-) and this is still a bit much for me. I've implemented a first pass of a container for external data and got it working on some of my collections. I've included the (first pass of the) base DBContainer and DBContained objects for criticism, and would be very grateful if anyone would like to take a crack at it. It looks like an interesting approach--more low-level than I would have expected for a first cut, and *maybe* more low-level than necessary. I wish I had more time to look at it. Keep in mind, this is my first time working with the system, so I'm sure I'm going about some things the wrong way. In particular, I already think: 1) Instead of have the contained object update the container, I should rely on the event notification system. Events are a tool for disconnected notification. calling a method on an object is sending a message directly to the interested party. Not everything should be an event. If a communication between two components is a core aspect of your design, maybe direct method calls are more appropriate. 2) Right now, the system works by translating objects at the border (in IExternalContainer). Some translation is necessary, for instance, to move from mx.DateTime to datetime.datetime, but still I think I should somehow be making use of the adaptor interface. If there's not an object to adapt then you have to start somewhere. My glance at the code seemed to show that you were making a reasonable choice. Another approach might be to have an abstract row object that could represent any columns (a dict or something), and named adapters registered for the row interface plus the name of the generating table. I dunno, do what your app needs and refine it as you discover what works. 3) Along these same lines, IDBContainer._containedType should really be an interface (Object( schema = IDBContained )) Note: is there a tutorial on writing containers anywhere I should have read? I mainly figured this out by banging on it and fishing around in the code. I'd love to figure out, for instance, what is really happening with the traversals (with some interaction diagrams). I do think it was harder than it should have been. (But, then again, I think that about most things...:)) Don't know of a tutorial. Sounds like you are interested in traversal, though, which is different. Look at zope.app.traversing, or zope.app.container.traversal. The headline is that there are two kinds of traversal: URL path traversal and TALES path traversal. They have different adapters. BTW in my humble opinion, ILocation.__name__ is not well named. When I first got an error referring to __name__ I thought it was expecting a class object. And what happens when, for some strange reason, someone wants to put a class in a container, and doesn't like its default name? Not sure if that's a real use case for an ILocation. That said, it's a reasonable POV to say that Zope shouldn't claim __*__ names. But we do, so, well, yeah, we do. ;-) Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 Developer's LiveBook
On Tue, 14 Feb 2006 10:15:50 -0700 Paul Dumais [EMAIL PROTECTED] wrote: Hi everyone, Do we start from scratch? Can we use any of the material from Stephan or Phillip's books? The Zope 3 Developer's Handbook by Stephan Richter doesn't seem to have any copywrite notice on it (on line pdf version at least). Can someone tell me what are the restrictions on it's use? I don't know where Stephan Richter wrote his book, but I strongly suspect he did it in a country that is a signatory to the Berne Convention. (http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html) Most countries (including the US) are signatories to the Berne Convention. One element of that convention is for copyright to be ascribed automatically upon creation on a tangible medium -- even if no express copyright notice is present. In the US, a copyright notice is *optional* for all works created after March 1, 1989. I suspect that you are thinking of pre-1976 US Copyright law, where a copyright notice was much more important. Currently, however, the lack of copyright notice does not absolve the author of their copyright. In short, it is a very safe bet that Mr. Richter's book is copyrighted, and you would have to seek permission from the owner of the copyright (which may or may not be Mr. Richter) to use that text. Ron ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 Developer's LiveBook
On Tuesday 14 February 2006 12:15, Paul Dumais wrote: Do we start from scratch? I think you have to, because both current books have licenses that do not allow any other commercial use. Can we use any of the material from Stephan or Phillip's books? The Zope 3 Developer's Handbook by Stephan Richter doesn't seem to have any copywrite notice on it (on line pdf version at least). Can someone tell me what are the restrictions on it's use? That is not true. The online, PDF and paper version all have an appendix with the license of the book. See: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/CreativeCommonsAttributionNoDerivsNonCommercialLicense What form should it take? Should we make it a latex file and check-in changes via svn? Should it be a simple wiki? I would urge you to use latex or some other advanced format. ReST and other low-tech solutions will not provide you the flexibility you need to develop a printable book. What liscense if any should the document have? How do anonymous/ community users contribute and fix errors? If it is a community book, then make it the most open CC license you possibly can. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
RE: [Zope3-Users] newbie design questions for UI to external data
Gary, Thanks for the reply. On Feb 13, 2006, at 10:33 PM, Shaun Cutts wrote: Um... I guess I must have asked too many questions at once :) :-) and this is still a bit much for me. I've implemented a first pass of a container for external data and got it working on some of my collections. I've included the (first pass of the) base DBContainer and DBContained objects for criticism, and would be very grateful if anyone would like to take a crack at it. It looks like an interesting approach--more low-level than I would have expected for a first cut, and *maybe* more low-level than necessary. I wish I had more time to look at it. If there were anything more higher-level, I would be happy I will eventually be needing paged collections to, though, so I can't give up too much control. Keep in mind, this is my first time working with the system, so I'm sure I'm going about some things the wrong way. In particular, I already think: 1) Instead of have the contained object update the container, I should rely on the event notification system. Events are a tool for disconnected notification. calling a method on an object is sending a message directly to the interested party. Not everything should be an event. If a communication between two components is a core aspect of your design, maybe direct method calls are more appropriate. The problem now is that the default edit view uses __setitem__ for the contained object, so I get one db update per column, whereas (I hope!) the event is fired after all the column updates are complete. Not a problem for the prototype, but maybe annoying in production system when Postgres is busier with other users as well. Of course, I may be overriding the default edit view anyway So the problem isn't the coupling between DBContained and DBContainer per se. Its sort of like I want the editView to enforce a transaction protocol, and want to use the Event as a proxy for commit. Note: I don't think I want dirty object in the system; otherwise I could use a lazy protocol where the container just checks -- say at demarshalling time (but probably on shutdown at least, if we are interrupted?) -- whether it has any updates to write. If I did want to go to a lazy protocol, is there a way to register things for getting triggered on shutdown. 2) Right now, the system works by translating objects at the border (in IExternalContainer). Some translation is necessary, for instance, to move from mx.DateTime to datetime.datetime, but still I think I should somehow be making use of the adaptor interface. If there's not an object to adapt then you have to start somewhere. My glance at the code seemed to show that you were making a reasonable choice. Another approach might be to have an abstract row object that could represent any columns (a dict or something), and named adapters registered for the row interface plus the name of the generating table. I dunno, do what your app needs and refine it as you discover what works. I actually do have a row object from my database code... but (as I learned) it is a bit of a pain to use directly, since: 1) datatypes are somewhat non-standard (dates, particularly), and 2) it is a bit messy to use with annotations because Row uses __getattribute__, though this is probably a design flaw in the Row class hierarchy. My thought was that I might want to be adapting my row objects (or their interfaces to be precise). Indeed, I am, but in a nonstandard way, as IExternalDatabase-derivatives do the translation. My plan now is: have the DBContained base class be a protoadapter that does all the column datatype translations and validation; its subclasses will adapt specific Row-derived classes, which have concrete sets of columns. I guess there is no particular machinery to use to present this pattern: one hierarchy adapts another hierarchy? 3) Along these same lines, IDBContainer._containedType should really be an interface (Object( schema = IDBContained )) Note: is there a tutorial on writing containers anywhere I should have read? I mainly figured this out by banging on it and fishing around in the code. I'd love to figure out, for instance, what is really happening with the traversals (with some interaction diagrams). I do think it was harder than it should have been. (But, then again, I think that about most things...:)) Don't know of a tutorial. Sounds like you are interested in traversal, though, which is different. Look at zope.app.traversing, or zope.app.container.traversal. The headline is that there are two kinds of traversal: URL path traversal and TALES path traversal. They have different adapters. When debugging, I had a lot of problems understanding what was happening because I didn't understand how traversal was trying to get data... It would just be nice to have more design doc -- especially interaction diagrams -- to refer to
Re: [Zope3-Users] Zope 3 Developer's LiveBook
Am Dienstag, 14. Februar 2006 19:41 schrieb Paul Dumais: Thanks, everyone for your comments. I'm not sure how commited I am to doing this, but I might as well take the rock soup approach. A rock soup is better than no soup, and everyone else can add their favorite ingredients to make it into something tasty. I'm sure that I'll also try to give some ingredients for the soup! I like the latex approch. There is a latex to html converter that the python website documentation uses (at least some of it). That means we could just do a latex to pdf and a latex to html conversion say once each month after doing an svn up. I also think that pure Latex would be the best choice. It's convertible into a lot different formats and can be edited just using a simple text editor. Should I get svn commit permission on the zope.org site and do this on a branch there? Since we need to start from scratch there is nothing to branch. ;-) I think Jim Fulton is responsible for giving checkin permission to the Zope repository. I presume the ZPL liscense would apply in this case. Would it be better to set up a repository somewhere else and use a different liscence (GPL, LGPL, ...)? I'm not too savy with the different liscenses out there. I'm happy as long as anyone is free to make derivative works without getting permission. On 2/14/06, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 14 February 2006 12:15, Paul Dumais wrote: Do we start from scratch? I think you have to, because both current books have licenses that do not allow any other commercial use. Can we use any of the material from Stephan or Phillip's books? The Zope 3 Developer's Handbook by Stephan Richter doesn't seem to have any copywrite notice on it (on line pdf version at least). Can someone tell me what are the restrictions on it's use? That is not true. The online, PDF and paper version all have an appendix with the license of the book. See: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Boo k/CreativeCommonsAttributionNoDerivsNonCommercialLicense What form should it take? Should we make it a latex file and check-in changes via svn? Should it be a simple wiki? I would urge you to use latex or some other advanced format. ReST and other low-tech solutions will not provide you the flexibility you need to develop a printable book. What liscense if any should the document have? How do anonymous/ community users contribute and fix errors? If it is a community book, then make it the most open CC license you possibly can. http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 Developer's LiveBook
On Tue, Feb 14, 2006 at 09:15:42PM +0100, Florian Lindner wrote: I also think that pure Latex would be the best choice. It's convertible into a lot different formats and can be edited just using a simple text editor. Isn't Docbook a better choice? Is is specially designed for documents like this, and easily parsable. lots of tools around. It can (AFAIK) be read and written by Open Office or any text editor. -- __ Nothing is as subjective as reality Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] What attributes are made persistent
Hello,
in a class derived from Persistent, which attributes are stored? All or only
those thar are declared in the interface?
def __init__(self):
self.queue = {}
self.queue seem is empty each time I restart Zope.
Thanks,
Florian
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
On Feb 14, 2006, at 4:52 PM, Florian Lindner wrote:
Hello,
in a class derived from Persistent, which attributes are stored?
All or only
those thar are declared in the interface?
All.
def __init__(self):
self.queue = {}
self.queue seem is empty each time I restart Zope.
Mutable objects, such as sets, lists, and dicts, can't inform their
persistent parents when they change, so changes to them are not
persisted. Use a persistent mapping in the persistent package (or a
btree); or set obj._p_changed=True when the dict changes; or use an
immutable data structure that must be replaced on the object instead.
Gary
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
On 2/14/06, Florian Lindner [EMAIL PROTECTED] wrote:
Hello,
in a class derived from Persistent, which attributes are stored? All or only
those thar are declared in the interface?
All.
def __init__(self):
self.queue = {}
self.queue seem is empty each time I restart Zope.
That's because dictionaries are not derived from Persistent. Try PersistentDict.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Squid/Apache Caching
On 2/14/06, Chris Withers [EMAIL PROTECTED] wrote: Steve Wedig wrote: I'm in the planning stages for developing a Zope 3 application. It would be nice to know my http caching plan ahead of time. It seems that the two main options are squid and apache. I was wondering if the most flexible setup might be to have apache running behind squid, and zope behind apache. My personal preference is apache - squid - zope But that's 'cos I like Apache's rewriting and have more faith in it as a front-end proxy for sanitizing requests and the like... That's very interesting. If you understood Squid better do you think you'd leave out apache? Or perhaps that not the issue at all for you. I'm asking because in my company we've lots of apache experience but less so in squid. It's therefore a potential security risk to leave out apache. And what about the performance overhead? Any experience you can share? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
On 2/14/06, Lennart Regebro [EMAIL PROTECTED] wrote:
On 2/14/06, Florian Lindner [EMAIL PROTECTED] wrote:
Hello,
in a class derived from Persistent, which attributes are stored? All or only
those thar are declared in the interface?
All.
def __init__(self):
self.queue = {}
self.queue seem is empty each time I restart Zope.
That's because dictionaries are not derived from Persistent. Try
PersistentDict.
D'oh! That's confusing. Isn't there a class that gathers all of these in one.
It seems confusing, you derive from Persistent but only some are accepted.
Does that mean that there's PersistentFloat and PersistentTuple too?
If not, why *only* dicts?
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
Peter Bengtsson wrote:
def __init__(self):
self.queue = {}
self.queue seem is empty each time I restart Zope.
That's because dictionaries are not derived from Persistent. Try PersistentDict.
D'oh! That's confusing. Isn't there a class that gathers all of these in one.
It seems confusing, you derive from Persistent but only some are accepted.
Does that mean that there's PersistentFloat and PersistentTuple too?
If not, why *only* dicts?
No, this issue applies to mutable attributes..
self.a = 1.1
self.b = (1,2,3)
self.b = (4,5,6)
These will persist as is, because you're rebinding the attribute
(reference) each time.
However, for ...
self.queue[1] = 2
This doesn't rebind self.queue.
So another way you could 'persist' this change is ..
self.queue[1] = 1
self.queue = self.queue
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Squid/Apache Caching
On Feb 14, 2006, at 15:44, Peter Bengtsson wrote: On 2/14/06, Chris Withers [EMAIL PROTECTED] wrote: Steve Wedig wrote: I'm in the planning stages for developing a Zope 3 application. It would be nice to know my http caching plan ahead of time. It seems that the two main options are squid and apache. I was wondering if the most flexible setup might be to have apache running behind squid, and zope behind apache. My personal preference is apache - squid - zope But that's 'cos I like Apache's rewriting and have more faith in it as a front-end proxy for sanitizing requests and the like... That's very interesting. If you understood Squid better do you think you'd leave out apache? Or perhaps that not the issue at all for you. I'm asking because in my company we've lots of apache experience but less so in squid. It's therefore a potential security risk to leave out apache. And what about the performance overhead? Any experience you can share? In my experience (and I use both Apache and Squid HEAVILY) Apache's rewrite abilities are nothing short of amazing. Squids caching ability is nothing short of amazing. The ability of one to do the other's job is mediocre :) If mediocre is good enough for your application for that particular component, then... by all means use it :) -- (`-/)_.-'``-._Chris Cogdon [EMAIL PROTECTED] . . `; -._)-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
On 2/14/06, Peter Bengtsson [EMAIL PROTECTED] wrote: D'oh! That's confusing. Isn't there a class that gathers all of these in one. It seems confusing, you derive from Persistent but only some are accepted. Does that mean that there's PersistentFloat and PersistentTuple too? If not, why *only* dicts? As mentioned above, it applies to *mutable* objects. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter's value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.) An object's mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable. http://docs.python.org/ref/objects.html Instances of Persistent based classes know when they change. Like if you do:: clive.age = 28 Which is effectively ``setattr(clive, 'age', 28)``. As a persistent object, clive notices that an attribute is being set (even if it's replacing an existing value), and flags that 'clive' has changes that need to be saved. So again - here, it's the 'clive' object that's being updated in this case. The fact that the value is an integer doesn't matter. It's not changing. 28 is 28. But 'clive' is changing by having a new/updated 'age' attribute set. On the other hand, if you do:: clive.favoriteNumbers.append(13) 'clive' does not change. 'favoriteNumbers' changes. If favoriteNumbers is a regular Python list, the persistence machinery has no idea that it's changed. It's not being assigned to 'clive', it's already an attribute there and is not being replaced. So if it's not a PersistentList, it gets forgotten. If favoriteNumbers was a tuple, you couldn't append to it. You could do an addition, but in a form like this:: clive.favoriteNumbers = clive.favoriteNumbers + (13,) # Alternately clive.favoriteNumbers += (13,) This is doing assignment. 'clive' is getting a new attribute set, and as a Persistent object 'clive' can be set as needing its changes saved. It's not only dicts, it's dicts and lists (PersistentDict and PersistentList). I don't know if there's a PersistentSet. Python offers two sets since 2.3 - a mutable (list-like) one and an immutable (tuple-like) one. I imagine that if you use the mutable set (``sets.Set`` in 2.3, ``set`` in 2.4), you'd run into the same problems. But if you used the immutable set (``sets.ImmutableSet``, ``frozenset`` in 2.4) you wouldn't. Note that this issue affects not just ZODB persistence. If you used even the simple 'shelve' module that's in Python, you have the same issue unless you use a 'writeback' option: If the writeback parameter is True, the object will hold a cache of all entries accessed and write them back to the dict at sync and close times. This allows natural operations on mutable entries, but can consume much more memory and make sync and close take a long time. So as a way of making working with default mutable objects feel natural, this option makes shelve read and write its whole database, which would obviously be very expensive for the ZODB. So - just use PersistentList and PersistentDict (or look into BTrees for better storage options). For more details, visit the ZODB documentation on ZODB programming, and visit the section on modifying mutable objects: http://www.zope.org/Wikis/ZODB/FrontPage/guide/node3.html ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] What attributes are made persistent
Oh! And reference to related Persistence modules (persistent mappings, lists, BTrees): http://www.zope.org/Wikis/ZODB/FrontPage/guide/node6.html On 2/14/06, Jeff Shell [EMAIL PROTECTED] wrote: On 2/14/06, Peter Bengtsson [EMAIL PROTECTED] wrote: D'oh! That's confusing. Isn't there a class that gathers all of these in one. It seems confusing, you derive from Persistent but only some are accepted. Does that mean that there's PersistentFloat and PersistentTuple too? If not, why *only* dicts? As mentioned above, it applies to *mutable* objects. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter's value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.) An object's mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable. http://docs.python.org/ref/objects.html Instances of Persistent based classes know when they change. Like if you do:: clive.age = 28 Which is effectively ``setattr(clive, 'age', 28)``. As a persistent object, clive notices that an attribute is being set (even if it's replacing an existing value), and flags that 'clive' has changes that need to be saved. So again - here, it's the 'clive' object that's being updated in this case. The fact that the value is an integer doesn't matter. It's not changing. 28 is 28. But 'clive' is changing by having a new/updated 'age' attribute set. On the other hand, if you do:: clive.favoriteNumbers.append(13) 'clive' does not change. 'favoriteNumbers' changes. If favoriteNumbers is a regular Python list, the persistence machinery has no idea that it's changed. It's not being assigned to 'clive', it's already an attribute there and is not being replaced. So if it's not a PersistentList, it gets forgotten. If favoriteNumbers was a tuple, you couldn't append to it. You could do an addition, but in a form like this:: clive.favoriteNumbers = clive.favoriteNumbers + (13,) # Alternately clive.favoriteNumbers += (13,) This is doing assignment. 'clive' is getting a new attribute set, and as a Persistent object 'clive' can be set as needing its changes saved. It's not only dicts, it's dicts and lists (PersistentDict and PersistentList). I don't know if there's a PersistentSet. Python offers two sets since 2.3 - a mutable (list-like) one and an immutable (tuple-like) one. I imagine that if you use the mutable set (``sets.Set`` in 2.3, ``set`` in 2.4), you'd run into the same problems. But if you used the immutable set (``sets.ImmutableSet``, ``frozenset`` in 2.4) you wouldn't. Note that this issue affects not just ZODB persistence. If you used even the simple 'shelve' module that's in Python, you have the same issue unless you use a 'writeback' option: If the writeback parameter is True, the object will hold a cache of all entries accessed and write them back to the dict at sync and close times. This allows natural operations on mutable entries, but can consume much more memory and make sync and close take a long time. So as a way of making working with default mutable objects feel natural, this option makes shelve read and write its whole database, which would obviously be very expensive for the ZODB. So - just use PersistentList and PersistentDict (or look into BTrees for better storage options). For more details, visit the ZODB documentation on ZODB programming, and visit the section on modifying mutable objects: http://www.zope.org/Wikis/ZODB/FrontPage/guide/node3.html -- Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
