Re: Pluggable brains sample using Script (Python) (J Cameron Cooper)
Cameron, Cool! I knew it was going to be easy. Thanks :-) BTW, I noticed that once you get an instance of the object, you *can* read the attributes (which of course correspond to the columns from the SQL query), but it doesn't let me change the values unless I create "wrapper methods" inside the class. Is that a Zope security thing, bug, unimplemented feature... do you know? Thanks, Julian
I was wondering if somebody has a handy example on how to use pluggable brains inside python scripts. For the most part I've only seen the sample in which you have a class:
class MyDataClass: def getSomething(self): return self.field1 + self.field2
and then you have a DTML method that goes something like
<dtml-in myquery> <dtml-var getSomething> </dtml-in>
How would I access the MyDataClass if I were to write a python script rather than a DTML method?
Untested, but it should look very similar to this: for elt in context.myquery(parameter1="dog", parameter2="goose"): print elt.getSomething() The parameters are those of the ZSQL Method, if any. The example above assumes two dummy parameters. Depending on your architecture, 'context' might be 'container' or another variable. It might also be written like for elt in context.myquery(REQUEST=REQUEST): print elt.getSomething() if you're getting your parameters from the HTTP request. --jcc
BTW, I noticed that once you get an instance of the object, you *can* read the attributes (which of course correspond to the columns from the SQL query), but it doesn't let me change the values unless I create "wrapper methods" inside the class.
Is that a Zope security thing, bug, unimplemented feature... do you know?
I guess I can't really say, in that I don't have time to take a look at the source right now. If you would like my guess (which may very well not be worth the paper which it is not written on), I think this is probably intentional. Why? 1) it probably had to be expressly prohibited 2) allowing change to PBs would imply (to some, at least) a change in the source data, which doesn't happen. Unlike some of the newer parts of JDBC, changing the results of an SQL query in Pluggable Brain space does not have any effect on the actual stored data. If it did, it would be a nice little feature, but otherwise it would be an annoyance and (possibly) inconsistent. Depending on your mental model of how this sort of mapping works. So I imagine that locking it down was the most reasonable behaviour. (There are other areas in Zope, I believe, where this happens.) If you like, you can think about it as an unimplemented feature that has been safeguarded, although I doubt this was ever the original intent. Someone with reasonable SQL knowledge and a good bit of expertise into Zope/Python introspection might be able to make this real without too much work (or maybe not.) But don't hold your breath. --jcc
On Tue, 15 Apr 2003 21:15:35 -0500 GMT (..4:15 where i live(GMT+2) ) Julian Sanchez asked the Zope mailinglist about the following: JS> BTW, I noticed that once you get an instance of the object, you *can* read JS> the attributes (which of course correspond to the columns from the SQL JS> query), but it doesn't let me change the values unless I create "wrapper JS> methods" inside the class. JS> Is that a Zope security thing, bug, unimplemented feature... do you know? It has at least been reported as a bug by both me and Dieter Maurer IIRC - although Dieter's report seems to be lost. http://collector.zope.org -- Geir Bækholt
participants (3)
-
Geir Bækholt -
J Cameron Cooper -
Julian Sanchez