April 2001 - Zope-Dev

SV: [Zope-dev] CoreSessionTracking
by Magnus Heino (Rivermen) 23 Apr '01

23 Apr '01

> The onStart method will be called when a session data object > is created. > Neither of the calls you show here create a session data > object. Something > like "Session.getSessionData()" would, however. Ah. I read "when a session starts, you may call an external method or PythonScrip" and thought that the session started when I received a new token... Thanks! /Magnus

1 0

CoreSessionTracking
by Magnus Heino (Rivermen) 23 Apr '01

23 Apr '01

Is onStart and onEnd broken in the CoreSessionTracking (0.8) product? (Or am I broken? :-)) I have a folder /Radio Within that folder I have a "Session ID Manager" and a "Session Data Manager" named Session. "Session onStart method path" of the "Session ID Manager" is set to /Radio/onStart I have an external method /Radio/onStart that does work if called standalone, from zLOG import LOG, WARNING def onStart(sdo): LOG('session started', WARNING, 'session started') but it never gets called when I call my index_html; <dtml-var standard_html_header> <dtml-var "Session.getToken()"> <dtml-if "Session.isTokenNew()"> Token is new. <dtml-else> Token is not new. </dtml-if> <dtml-var standard_html_footer> Ths index_html method does return 'Token is new', but no onStart method is being called. What am I missing??? I have read the helpfile over and over again, but it still doesn't work. ? /Magnus

2 1

[OT] Re: [Zope-dev] Introducing a New Concept on Advanced Garbage Treatment Process
by Dieter Maurer 23 Apr '01

23 Apr '01

zwj writes: > Introducing a new concept on advanced garbage treatment process, and licensing patents > For details, please reference the web site: > http://zwj5382.3322.net > http://zwj5382.163.net > The inventor would like to assign exclusive patent license to anyone who is interested in patented advanced garbage treatment process technology. For patent license, please contact the inventor via E-mail: > zwj88zww(a)371.net This seems to be another of these stupid patents awarded in the US, a la "one-click buying", "rendering documents via stylesheets", "using computers to sell bakery products online". I have the feeling that this is a sign that capitalism enters its final stages. It starts to no longer foster innovation. Advocates, not technicians, have taken over to make money out of the most trivial ideas. I hope *very much* that such nonsense can be prevented in Europe. But maybe, I hope in vain.... Dieter

3 2

.zexp's
by Zopista 23 Apr '01

23 Apr '01

Just ran into a problem with a newbie where they couldnt figure out where to import the zexp, if its a product it should go in /Control_Panel/Products, if not it should go in the ZODB. I couldn't think of an obvious way to tell, so I just had a look in the zexp and came up with this: file = open(infile, 'r') if string.find(file.readline(), 'App.Product') >= 0: print "%s is a product zexp, go to Control_Panel" % infile Can anyone think of a better way? It would be figure out where to stick this in ExportImport.py so it would give nicer error messages... Cheers -- Andy McKay

1 0

Re: [Zope-dev] ZPatterns AttributeProvider question
by cs＠comlounge.net 22 Apr '01

22 Apr '01

Hi! Just a quick note as it's quite late already (more tomorrow): > In the early days of ZPatterns, I assumed that I would create SQL > providers, LDAP providers, and suchlike gizmos. Later, it became clear > that it was more useful to have a simple "glue" language to allow > harnessing the full power of Zope in the context of events happening to > objects. I still toy with the idea of making an "SQL attribute provider", > however, that would be based on the ZSQLMethod object and add some > ZPatterns hooks to it, but it's not a big priority. Its main value would > be to cut down on some repetitive typing between one's SQL statements and > SkinScript statements. Well, exactly this was the intention of programming this as I was a bit bored by all this typing, exactly when the attribute lists are getting longer. So right now I define it once in the ZClass, press the "Read ZCLass propsheet" button and the my attribute provider sets everything up itself.. (it also saves me from typing errors..) Actually I did it with SkinScript before but thought some simple plugin would be nicer.. But thanks for explaining the inner workings in some more detail (maybe I should put this into some howto or so? or it might be put into the ZPatterns wiki..), as this really should help (not only me I guess :) I will comment more on this tomorrow.. (at least I got some idea how I might solve my problem... though I thought this some times before already.. ;-) And the other possible option would be (as Steve suggested once on IRC) to create some wizard which sets up all the SkinScript methods and ZSQL methods in one go.. Anyway, more about it tomorrow. good nite.. Christian -- COM.lounge http://comlounge.net/ communication & design info(a)comlounge.net

1 0

Re: [Zope-dev] ZPatterns AttributeProvider question
by cs＠comlounge.net 22 Apr '01

22 Apr '01

Hi! A little update.. Actually I was mistaken and SetAttributeFor() is called. Just _objectChanged() is not called in that case.. and thus my attributes are not stored to the database. Also commit() is not called at all in this case. It get's called once when the subtranscation is committed but not after some data has changed (which happens after that). Printing _v_status_ in SetAttributeFor() also gives me "Changed", thus this seems right. Maybe some more code will help (just the important pieces): def _objectAdded(self,client): """ store cached data in database """ ... here we do an sql query to insert things in database ... def _objectChanged(self,client): """ store cached data in database """ ... here we do an sql query to update things in database ... def _objectAdding(self,client, _tmap={ None:AddedStatus, DeletedStatus:ChangedStatus, ChangedStatus:AddedStatus } ): t = client._getTokenFor(self) s = t.status t.status = _tmap.get(s,s) # we need to do a commit here in order to store the record into the database! # and we need to have it stored as an AttributeFor() of the primary key will # return None otherwise (as this also just makes a query). client.commitSubtransaction() def _SetAttributeFor(self,client,name,value): """Set the attribute and return true if successful""" # attribs stores the attributes we care about if name in self._attribs.keys(): client._getCache()[name]=value client.__dict__[name]=value; client._p_changed = 1 return 1 return None So _objectChanging() is not overridden, the rest I have ommitted.. So as you also can see I already do a subtransaction commit but it does not seem to help for this problem.. regards, Christian PS: It might also be that I am simply blind ;-) But somehow ZPatterns always confuses me, especially the inner workings ;-) -- COM.lounge http://comlounge.net/ communication & design info(a)comlounge.net

2 2

Re: [Zope-dev] ZPatterns AttributeProvider question
by Steve Alexander 22 Apr '01

22 Apr '01

Phillip J. Eby wrote: > Steve Alexander wrote: > >> As a simpler workaround, you can use >>your_object.commitSubtransaction() instead of redirecting to a new page. >> > Um, this shouldn't be the issue here. _SetAttributeFor() should be called > when the attribute is set; it's not transaction-driven. Something weird is > happening with Christian's situation that I haven't investigated yet. I agree. However, if Christian's problem can be worked-around by redirecting before setting attributes, then it should also be workaroundable by calling commitSubtransaction. > Actually, the status should be AddedStatus, and it should stay that way > throughout the transaction, unless the object gets deleted in the same > transaction. That's what I'd originally thought. Then I (mis-?)read the code again... The __set_attr__ method of DataSkins.py says: self._objectChanging(name) The _objectChanging method says: if self._v_status_ is not ChangedStatus: d[_v_dm_]._objectChanging(self) d[_v_status_] = ChangedStatus I don't see an exception for if _v_status is already AddedStatus. -- Steve Alexander Software Engineer Cat-Box limited

1 0

Re: [Zope-dev] ZPatterns AttributeProvider question
by cs＠comlounge.net 22 Apr '01

22 Apr '01

Hi! > >Yes, as said above it registers for handlers and attributes. Also > >_objectChanged and _SetAttributeFor() etc. are called. They're just not > called > >directly after creating the object (when being in the same request that is). > > _objectChanged() is a transaction-commit message. You'll only get it when > the (sub)transaction commits. You'll receive _objectChanging() just > *before* the object changes. Yep, that's how I understood it. That's also working. > As for _SetAttributeFor(), it should be called at the time > manage_changeProperties executes, not at object creation. Are you sure > that you have it properly named and that it isn't still being defined by > one of your ancestor classes instead? The "AttributeProvider" and > "GTMixin" base classes in ZPatterns implement _SetAttributeFor() by simply > noting the change for later. If you don't override this behavior, your > class won't see _SetAttributFor() itself. Well, it actually is working, just not directly after creating the new object. So what I do now as workaround is dtml method 1: - creates new object via newItem() - redirects to dtml method 2 dtml method 2: - retrieves the newly created object with getItem() - calls manage_changeProperties on that object This is working. Putting the manage_changeProperties directly after the newItem() is not working. I've also tried retrieving the new object directly after newItem() and calling manage_changeProperties on that but this also did not work. (so it is named correctly as otherwise it wouldn't be called either in dtml method 2). So the main problem is: SetAttributeFor() is not called (and also _objectChanging() is not called) in the same request cycle after creating a new object. They're called however in the "next" request after retrieving it with getItem(). Maybe it helps if I publish the source somewhere? It's gonna be some public product anyway. regards, Christian -- COM.lounge http://comlounge.net/ communication & design info(a)comlounge.net

3 2

[] vs () in dtml-in: is this a bug ?
by Stefane Fermigier 22 Apr '01

22 Apr '01

Hi, please try this as a DTML Method: <dtml-let l="[[1, 2], [3, 4]]"> <dtml-in l> <dtml-var "_['sequence-item']"><br> </dtml-in> </dtml-let> <dtml-let l="[(1, 2), (3, 4)]"> <dtml-in l> <dtml-var "_['sequence-item']"><br> </dtml-in> </dtml-let> Why should the two results differ ? S. -- Stéfane Fermigier, Tel: 06 63 04 12 77 (mobile). http://nuxeo.com/ & http://portalux.com/ & http://aful.org/ "Amazon: we patent the dot in .com"

2 2

"pydoc" for Zope - another great documentation finding tool
by Dieter Maurer 22 Apr '01

22 Apr '01

I installed Python 2.1 and checked what great new things are there: they are numerous! As you know, I am a fan of documentation - reliable documentation, if possible directly extracted from the source. Therefore, the new Python documenter "pydoc" was very attractive for me. I had to tweak "Zope" and "pydoc" a bit such that they work nicely together: * "pydoc" imports the modules to find out about its content. Zope does not like to be imported, when another Zope process is running. Solved by calling "FileStorage.FileStorage" with the "read_only" parameter in "Zope.__init__", if instructed by an environment variable * "pydoc" is slightly confused by some of Zope's extension classes: it wants any class to have a "__module__" attribute. Zope's extension classes do not have it. Solved by wrapping pydoc's "__module__" access in an "try .... except". * "inspect" does not understand "Python Methods" (and other Zope methods). Correspondingly, Zope class documentation was almost empty. Solved by defining "implementsMethodInterface" and replacing "inspect.ismethod" by this function (at runtime). After these tweaks, "pydoc" can document Zope code. It is a bit overwhelming: The "pydoc" authors decided to document inherited methods with the class itself. As a consequence, for each Zope class, hundreds of mostly irrelevant methods are documented. But it should be easy to change this to get something similar to "javadoc": summary information for inherited methods. Already in the current state, I think, it is a great help for Zope developpers. If there is interest, I can post my changes. Dieter

1 0