- Zope - Zope lists

Re: [Zope] persistence and dictionaries
by Tres Seaver 09 Dec '00

09 Dec '00

Matt <matt.bion(a)eudoramail.com> wrote: > > Chris, this was my original confusion .... the two places below where you say > > "You can put instances which do not inherit from Persistence.Persistent in > your database. They just won't "stick". They'll hang around until the > server is restarted or for an undetermined amount of time during normal > operations." > > "No. It'll work for "a while" or until the server is restarted. :-)" > > actually do persist after restarts ... that's what confused me, they wouldn't > go away and they should!! I think that the confusion here lies in the word, "Peristent". Because it uses the standard Python pickling mechanism, the ZODB can store all kinds of objects (integers, strings, etc., as well as class instances). The ZODB is, however, broken up into a collection of individual records, each of which contains a series of pickles (one per transaction). Objects which are not "ZODB aware" get stored in the pickle of their container (actually, the nearest one which *is* persistence-aware). Deriving your class from Persistence.Persistent says to the ZODB, "put me in my *own* pickle, not it the pickle of my container". The other thing Persistence does is hook the '__setattr__' method, so that changes you make to the object's attributes automatically register it with Zope's transaction machinery; this registration means that a new pickle gets saved to the ZODB at the end of the transaction. Objects which do not derive from Persistence must handle this registration themselves, or else risk having such changes be lost whenever they are reloaded. Globals.PersistentDictionary is a wrapper class which does does this kind of registration in its '__setitem__' method. HTH, Tres. -- =============================================================== Tres Seaver tseaver(a)digicool.com Digital Creations "Zope Dealers" http://www.zope.org

2 1

ZPublisher and func(self,*args,**kw)
by Andreas Jung 09 Dec '00

09 Dec '00

Inside a product I tried to replace the following function def myfunc(self,arg1='',arg2='',REQUEST=None): by def myfunc(self,*args,**kw): to get a more generic interface. However in every case "args" and "kw" are empty when I output their contents inside the function. Bug or feature ? Andreas

2 1

Using Analog and Zope Zserver
by Scott 09 Dec '00

09 Dec '00

Hi All, I'm using analog to analyze my server logs, however I can't figure out how to tell analog to treat everything without an extension as a page. Or perhaps more accurately everything without a "." in it's name. I have read numerous posts to this list regarding index_html or *_html, but much of my site is composed of Zwiki pages, which do not follow that convention. I'm currently playing with the regular expression functions, but I'm not exactly familiar with regex. Any ideas? What is everyone else using when using Zserver, vs. Apache, IIS, etc. Thanks - Scott

1 0

quick python book - question about the feedback form example
by Lee 09 Dec '00

09 Dec '00

Hi, Finally got my hands on The Quick Python book and have read the first 13 chapters. I've now jumped to chapter 26, "Using Zope", to try out some of the examples there. I'm havng a problem with the feedback form example (p326) and I'd be really grateful if someone could point out what I am doing wrong. - I created a directory in the root called 'feedback' and to this I added a DTML document, 'index_html'. I see no probs with this but maybe someone could confirm that the post action is correct for me. index_html ------------- <dtml-var standard_html_header> <FORM ACTION="/cgi-bin/feedback/save_feedback" METHOD="POST"> Type of feedback: <SELECT NAME="feedback_type"> <OPTION>Compliment <OPTION>Criticism </SELECT> <p> Your comments: <TEXTAREA NAME="comments"></TEXTAREA> <INPUT TYPE="SUBMIT" VALUE="Submit Feedback"> </FORM> <dtml-var standard_html_footer> - I then create a python method called 'feedback.py' containing the following: feedback.py -------------- """feedback.py: A simple feedback form application""" def save_feedback(feedback_type, comments): """ A function to handle submitted feedback form data""" # Open a file for appending to save the feedback # creating the file if necessary try: file=open("feedback_data", "a") except IOError: file=open("feedback_data", "w") # Save the data file.write("Feedback type: %s\n" % feedback_type) file.write("Comments: %s\n\n % comments) file.close() return "Thankyou for your feedback!" ^ On the Python method addition screen I use feedback(.py) as the ID + title and insert "feedback_type, comments" in the parameter list. Of course, this results in an error SyntaxError & Invalid token. I tried to modify it by taking out the first 2 lines of the above code, renaming the method 'save_feedback' but still no success. I'm unsure whether the return statement will do anything in Zope also. Can anyone help? - Best regards, Lee (with 10 crossed fingers & toes) -- Lee Reilly mailto:lee.reilly@ntlworld.com http://www.footkick.co.uk/lee

2 1

customize zope manage_main
by richard lanham 09 Dec '00

09 Dec '00

I have looked at many of files in lib/python/app and a other folders in the zope installation. I am looking for a way to change the interface a little. I see some recognizable stuff there, but can't figure out how most of the pages are created, how I could change them. I want to add a frame to the edit page so I can submit while editing without refreshing the page. I would have to put a frame and javascript function I wrote, and include below because it is very useful. This makes editing long docs in a textarea tolerable. I use it on a site with a lower frame where the user can see their changes and not lose their place as they edit/save. thanks, Richard function bgSubmit(frm) { frmHide = parent.frames["hidden"].document var nd="<form name='" + frm.name + "' action='" + frm.action + "' method='" + frm.method + "'>" for (i=0;i<document.forms[frm.name].elements.length;++i) { elem=document.forms[frm.name].elements[i] if (elem.type=="select-one" || elem.type=="select-multiple") { nd+="<select name='" + elem.name + "'" if (elem.type=="select-multiple") {nd+=" multiple "} nd+=">" for (x=0;x<elem.options.length;++x) { nd+="<option " if (elem.options[x].selected) {nd+="selected "} nd+="value='" + elem.options[x].value + "'>" + elem.options[x].text + "</option>" } nd+="</select>" }else if (elem.type=="textarea"){ nd +="<textarea name='" + elem.name + "'>" + elem.value + "</textarea>" } else { nd +="<input type='" + elem.type + "' name='" + elem.name + "' value='" + elem.value + "'" if (elem.checked) {nd+=" checked "} nd+=">" } } nd+="</form>" frmHide.open("text/html"); frmHide.write( nd ); frmHide.close(); parent.frames["hidden"].document.forms[0].submit() } //this function assume you have a frame named "hidden" and takes a form object as arg, e.g., bgSubmit (window.document.frmToSave)

1 0

Re: [Zope] SECURITY alert and hotfix release
by Andrew Kuchling 09 Dec '00

09 Dec '00

On Fri, Dec 08, 2000 at 05:40:13PM -0500, Shane Hathaway wrote: > AFAICT 2.1.6 is not vulnerable. Verifying this on our server, this turns out to be quite correct; Zope 2.1.6 does not demonstrate the problem repaired by the hotfix. --amk

1 0

newbie question -- database list/report with sort by column header
by John Cappelletti 09 Dec '00

09 Dec '00

I am listing the results of a database query using dtml-in. I'd like to be able to give the user the option to re-sort the list by clicking on a column header. ok... I'm starting small with a form and radio buttons to allow the user to specify the sort. I've created what I believe to be a global variable for this page using the property screen. The variable is to capture the column name for the sort. My simple question is how do I assign a value to this variable inside of the dtml method! I'm not finding a description of variable assignment in the documentation (yeah, I must be missing the obvious). Any pointers would be appreciated. (also, know if anyone has implemented interactive sort by column header?) thanks, John Cappelletti AverStar, Inc. 1593 Spring Hill Road, Suite 700 Vienna, VA 22182-2249 Tel: (703) 827-2606 x 4291 (also, 301 443-7509) Fax: (703) 827-5560

4 3

StructuredText with Metapublisher content
by olpa＠sybcom.de 09 Dec '00

09 Dec '00

Hi, when I render a DTML-Method abc containing structured text content with <dtml-var abc fmt=structured-text>, the output is correctly rendered. when I render the content of a MetaPublisher entry with <dtml-var "mp_entries..." fmt=structured-text>, then the output is not correctly rendered. Only constructs like **bold** are recognized. No tables or lists or paragraphs. Did anyone experience this with a solution ? Regards, oliver --- ..you could spend *all day* customizing the title bar. Believe me. I speak from experience." (By Matt Welsh) --- Oliver Pabst .-------------------------. mailto:olpa@sybcom.de : : phone :+49 681 56600600 : project department : SYBCOM GmbH fax :+49 681 56600660 : : http://www.sybcom.de

1 0

Re: [Zope] persistence and dictionaries
by Matt 09 Dec '00

09 Dec '00

Ok, here are some of the offending bits out of my boringplus product .... which I can send again if people want. I have another product that keeps a dictionary of cookies so I can see how many times someone uses the back button to access the same forms page again. This worked as expected, where I had to issue an _p_changed=1 to get them to persist. But I am doing a similar thing below, or so I thought, once with a dictionary in the product and once in a dictionary within a class that does not inherit Persistent. This is what is confusing. Through restarts etc, everything perisists class Boring( OFS.SimpleItem.Item, # A simple Principia object. Not Folderish. Persistent, # Make us persistent. Yaah! Acquisition.Implicit, # Uh, whatever. AccessControl.Role.RoleManager # Security manager. ): def __init__(self, id, title=''): self._things = {} self._more = myClass.MoreStuff() def manage_edit(self, title, REQUEST=None): if REQUEST is not None: if REQUEST.has_key('thing'): self._things[REQUEST['thing']] = REQUEST['thing_value'] self.addToMore(REQUEST['thing'],REQUEST['thing_value']) def addToMore(self,name,value): self._more.addStuff(name,value) return "" class MoreStuff: def __init__(self): self._stuff = {'animal':'monkey'} def addStuff(self,stuff_name,stuff_item): On Sat, 09 Dec 2000, Jonothan Farr wrote: > Maybe I'm mistaken, but it seems like you can put an instance of an object that > doesn't inherit from Persistent into the ZODB just fine, but its contents won't > persist, so you'll always end up with a copy of the object as it was first added > to the database. > > --jfarr > > ----- Original Message ----- > From: "Chris McDonough" <chrism(a)digicool.com> > To: <matt.bion(a)eudoramail.com> > Cc: <zope(a)zope.org> > Sent: Friday, December 08, 2000 11:57 AM > Subject: Re: [Zope] persistence and dictionaries > > > > Huh. If they do, it's by chance only. I'd be hard-pressed to explain it. > > > > Do they inherit from *anything*? > > > > ----- Original Message ----- > > From: "Matt" <matt.bion(a)eudoramail.com> > > To: "Chris McDonough" <chrism(a)digicool.com> > > Cc: <zope(a)zope.org> > > Sent: Friday, December 08, 2000 2:30 PM > > Subject: Re: [Zope] persistence and dictionaries > > > > > > > Chris, this was my original confusion .... the two places below where you > > say > > > > > > "You can put instances which do not inherit from Persistence.Persistent in > > > your database. They just won't "stick". They'll hang around until the > > > server is restarted or for an undetermined amount of time during normal > > > operations." > > > > > > "No. It'll work for "a while" or until the server is restarted. :-)" > > > > > > actually do persist after restarts ... that's what confused me, they > > wouldn't > > > go away and they should!! > > > > > > regards > > > Matt > > > > > > Chris McDonough wrote: > > > > > > > > Thanks for the reply, that is really useful. There are a couple of > > things > > > > > though that still don't add up. Firstly, you say below, as do all the > > > > ZODB > > > > > documents that "Custom" classes can certainly persist, they just need > > to > > > > mix in > > > > > the "Persistence.Persistent" class as a base class. Well, in my > > example I > > > > > attached in my first email, my product certainly has > > > > Persistence.Persistent, > > > > > but my second class that I add to this one does not, yet it still > > > > persists. > > > > > There was an email sometime ago on the mailing list that told someone > > that > > > > this > > > > > was why their product instances disappearing from the ZODB. > > > > > (the ref for the original email is : > > > > http://www.egroups.com/message/zope/44263 > > > > > ... I can't find the reply again.) > > > > > > > > > > > > > You can put instances which do not inherit from Persistence.Persistent > > in > > > > your database. They just won't "stick". They'll hang around until the > > > > server is restarted or for an undetermined amount of time during normal > > > > operations. > > > > > > > > > So my current understanding would be that any classes you want to add > > in > > > > do not > > > > > need to derive from Persistence.Persistent, and if it is pickleable > > then > > > > all > > > > > should be fine if you call on instances of that object within you > > product. > > > > > > > > No. It'll work for "a while" or until the server is restarted. :-) > > > > > > > > > The next part that worried me came from the "python product tutorial" > > > > > http://www.zope.org/Members/hathawsh/PythonProductTutorial > > > > > > > > > > This stated that the class dictionary self.votes = {} needed to be > > changed > > > > to > > > > > self._votes = Globals.PersistentMapping() so that updates to it > > persist. > > > > > Hence my query about dictionaries. > > > > > > > > This was for convenience, I'd imagine. > > > > > > > > > I also noticed your comment about __setstate__ . What is it about > > this > > > > that is > > > > > dangerous. > > > > > > > > Nothing implicitly dangerous, but it can get confusing if you have > > multiple > > > > revisions of your product and you use variables caused by __setstate__. > > > > Also, once you add a __setstate__ which modifies the object in-place, > > > > there's a likelihood that it can never go away (you're can never be sure > > if > > > > all instances have been updated). > > > > > > > > > Recently I built a product out of some python classes I wrapped > > > > > around 4DOM, and since 4DOM documents do not seem to persist(well the > > > > document > > > > > does, but it loses all its children), then I persisted them to the > > local > > > > file > > > > > system, since I needed to do that anyway for what I was doing. > > Setstate > > > > seemed > > > > > to work nicely to bring them back, though watching its behaviour I > > noticed > > > > that > > > > > it was called very often by zope. > > > > > > > > Sure, that works... although at that point you're creating your own > > object > > > > database. :-) > > > > > > > > > > > > > > Chris McDonough wrote: > > > > > > > > > > > All pickleable Python primitive types (strings, dictionaries, lists, > > > > Nones, > > > > > > integers, floats, longs, etc.) can live in the ZODB. They can > > persist > > > > just > > > > > > like instances that inherit from the Persistent class. > > > > > > > > > > > > I think you read a little too much in to the fact that you need to > > > > "treat > > > > > > mutable objects immutably" when working with them in the ZODB. This > > > > > > statement doesn't mean that these kinds of objects can't be saved in > > the > > > > > > ZODB, it just means you need to treat them specially when putting > > them > > > > in > > > > > > the database. > > > > > > > > > > > > For instance, if you were doing this inside of an external method: > > > > > > > > > > > > def amethod(self): > > > > > > self.mydict = {} > > > > > > self.mydict['a'] = 1 > > > > > > > > > > > > (where self is the persistent object that is usually the external > > > > method's > > > > > > "container") > > > > > > > > > > > > It wouldn't work as you expected. Although you'd see an 'a' in > > mydict > > > > for a > > > > > > little while in further accesses to it, 'mydict' would eventaully > > show > > > > up as > > > > > > an empty dictionary on the first access of it after it was expired > > from > > > > the > > > > > > RAM cache (after it was 'ghosted'), because the last thing that the > > ZODB > > > > > > "saw" (via the __setattr__ on 'self' and a subsequent transaction) > > was > > > > you > > > > > > setting a empty dictionary. > > > > > > > > > > > > Persistent objects (like "self" in the above example) are only smart > > > > enough > > > > > > to notice changes to themselves that happen through their > > __setattr__ > > > > (e.g. > > > > > > self.mydict = {} calls self's __setattr__). Mutating the attribute > > > > 'mydict' > > > > > > above "in-place" (via self.mydict['a'] = 1) does not trigger self's > > > > > > __setattr__, so the ZODB never notices that "mydict" got changed. > > > > > > > > > > > > There are two ways to handle this. The first is to treat mutable > > > > attributes > > > > > > "immutably" via assigning to a temporary variable and then making > > sure > > > > the > > > > > > persistent container's __setattr__ gets called: > > > > > > > > > > > > def amethod(self): > > > > > > dict = {} > > > > > > dict['a'] = 1 > > > > > > self.mydict = dict # trigger persistence mechanism implicitly > > > > > > > > > > > > The second is to use the _p_changed attribute of the persistent > > object > > > > on > > > > > > which the primitive is set. This explcitly tells the persistence > > system > > > > to > > > > > > include the object on which it's set into the current transaction: > > > > > > > > > > > > def amethod(self): > > > > > > self.mydict = {} > > > > > > self.mydict['a'] = 1 > > > > > > self._p_changed = 1 # trigger persistence mechanism manually > > > > > > > > > > > > Variations on this theme extend to list methods too (e.g. > > list.append, > > > > > > list.pop, etc.) > > > > > > > > > > > > "Custom" classes can certainly persist, they just need to mix in the > > > > > > "Persistence.Persistent" class as a base class. > > > > > > > > > > > > As long as you obey this (slightly annoying, but necessary) rule, > > you > > > > > > shouldn't need to use PersistentMapping (it's really just a > > convenient > > > > > > wrapper that does this "magic" for you) or make any other wrappers > > for > > > > other > > > > > > mutable objects. > > > > > > > > > > > > I don't know why you're using __setstate__, but ummmm.. I won't go > > > > there. > > > > > > :-) I didn't look at your product, but I don't think I need to to > > > > answer > > > > > > your question... > > > > > > > > > > > > > Hi I am trying to get a handle on how I should handle peristence > > in my > > > > > > > python products. I have read all the ZODB documents and all the > > > > Product > > > > > > > tutorials, which all led me to believe that 1) mutable objects > > such as > > > > > > > lists and dictionaries are not persistent and that updates to > > these > > > > will > > > > > > > not be implicitly saved into the ZODB, and 2) that custom classes > > > > would > > > > > > > certainly not persist. That all seemed fine, and I used persitent > > > > > > > mapping and __setstate__ to fill things back in where necessary. > > But > > > > > > > then I decided to demonstrate that persitence does break as > > suggested. > > > > > > > > > > > > > > I used boring product, added a dicitonary and a custom class that > > > > > > > contains it's own dictionary.... let the user update name : value > > > > pairs > > > > > > > for both, and print the contents through index.dtml > > > > > > > > > > > > > > The problem is that everything persists fine !!!! through > > restarts, > > > > > > > everything? > > > > > > > > > > > > > > Why does it work??? shouldn't it not? > > > > > > > > > > > > > > I have attached the modified boring product .... boringplus ..... > > it's > > > > > > > dead simple to follow if you have made products before. > > > > > > > > > > > > > > Any explanation would be really nice. > > > > > > > > > > > > > > regards > > > > > > > Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Zope maillist - Zope(a)zope.org > > > http://lists.zope.org/mailman/listinfo/zope > > > ** No cross posts or HTML encoding! ** > > > (Related lists - > > > http://lists.zope.org/mailman/listinfo/zope-announce > > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > > > > > > > > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > > > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev )

2 3

PythonMethod (0.1.6) ZEO weirdnesss
by Dyon Balding 09 Dec '00

09 Dec '00

Hi, We've got a 2 client ZEO cluster working fine, with a number of PythonMethods (ver 0.1.6). When I tried adding a 3rd ZEO client, which I am pretty sure is set up in the same way as the other clients, PythonMethods created via the original clients barf when viewed on the new client. Wierdly, PythonMethods created in the new client work fine on all three. Any idea what is happening here? thanks d The traceback is as follows: Traceback (innermost last): File D:\dyon\DYONZO~1\lib\python\ZPublisher\Publish.py, line 222, in publish_module File D:\dyon\DYONZO~1\lib\python\ZPublisher\Publish.py, line 187, in publish File D:\dyon\DYONZO~1\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File D:\dyon\DYONZO~1\lib\python\ZPublisher\Publish.py, line 171, in publish File D:\dyon\DYONZO~1\lib\python\ZPublisher\mapply.py, line 160, in mapply (Object: pytest) File D:\dyon\DYONZO~1\lib\python\ZPublisher\Publish.py, line 112, in call_object (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\PythonMethod.py, line 163, in __call__ (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\PythonMethod.py, line 144, in makeFunction (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\PythonMethod.py, line 126, in _newfun (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\VSExec.py, line 344, in UntupleFunction File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 260, in __init__ File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 267, in __init__ (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 287, in init_tuple (Object: pytest) File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 162, in __init__ File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 177, in __init__ File D:\dyon\dyonzope224\lib\python\Products\PythonMethod\zbytecodehacks\code_editor.py, line 217, in init_tuple ValueError: unpack tuple of wrong size -- Dyon Balding <dyon(a)devcoder.com.au>

1 0