Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
What you say is all perfectly true except: 1. In the example, just setting _p_changed=1 does _not_ lead to a conflict error. With the ineffectual code above it (that never gets executed) it _does_. So there _is_ some implicit magical stuff going on and ZOPE tries to take care that only subobjects change (but incompletely)! 2. You shouldn't use lists and dicts - it should say this on the front page. It is never really mentioned in any way that intuitively leads to such problems as we are now talking about. It isn't very obvious that things work like this when you look at the documentation, and 3. It is especially confusing that ZOPE behaves differently when using XML-RPC calls. From what you say, it should be the same within the ZOPE system as when using XML-RPC. It gets more complicated with XML-RPC though! All the stuff that you claim as being obvious really isn't all that obvious. And of course, once you've been burned by something like this and the confusion it engenders, you will only use PersistentMapping etc., but I still don't know what _exactly_ to expect from ZOPE in terms of behaviour with mutable objects that aren't Persistent (because of the XML-RPC inconsistency and the self._p_changed inconsistency both mentioned above). Ole 2005/12/18, Lennart Regebro [EMAIL PROTECTED]: On 12/18/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I know. This is just example code. Just imagine that both methods change completely unrelated sets of data in addition to not changing self.a. Well, yes, but since both a and also b is non-persistence aware lists, that means that you in fact change neither a or b, but self. If however, you do change unrelated sets of data, such as the persistence aware object self.a, and the persistance aware object self.b, then you do NOT get a conflict error. Actually, I don't think we're getting anywhere with this same dataset/different dataset distinction. It wouldn't happen in a database using application because there would be no transaction for self.a. You see, nothing happens to it, so why would there be one? There isn't one in this case either, unless you set self._p_changed = 1, which you of course do... This only happens when you mix your data with your code and have implicit transactions handled by the server. There is no mixing of data and code going on, so we are definitely not going anywhere with TAHT distinction. ;-) Yes, sorry, having non-persistent aware dictionaries or arrays, and then complaining that you have problems with persitency... But that's part of my point: I need to go out of my way to circumvent Python, and I need to be really careful, because using dicts and lists might still work. Nothing is enforced, and where it breaks is hard to predict. No, it's dead easy to predict, as soon as you understand that you should not modify non-persistent aware attributes, and expect that to work optimally. You may be right that doing that should raise an error, but I also don't exactly see how to make that happen. See the example for some major implicitness. What is implicit with it? I explained this above. Transaction handling in Zope (someone else pointed that out in this thread), Zope looking at the code to determine that self.a has changed (which isn't really documented anywhere obvious). I'm sorry, I still don't understand what implicitness you are talking about. It is obvious to me that you have misunderstood something. I don't know what yet, though. I think we might be misunderstanding each other because we both place different value on implicitness and explicit design of data inside code. I am mostly talking about what is, pragmatically, good programming and a supportive environment. No, I think the misunderstanding is that you are overcomplicating something that is really quite simple. But I'm not sure. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
1. In the example, just setting _p_changed=1 does _not_ lead to a conflict error. With the ineffectual code above it (that never gets executed) it _does_. So there _is_ some implicit magical stuff going on and ZOPE tries to take care that only subobjects change (but incompletely)! I strongly doubt it. Zope does not inspect code. There must be a problem in your testing. Note that if self.a is a standard list, the self.a.append(1) doesn't have any impact on the persistence mechanism or transactions either. Please, try it out. Delete the if clause and the append in it. 3. It is especially confusing that ZOPE behaves differently when using XML-RPC calls. From what you say, it should be the same within the ZOPE system as when using XML-RPC. It gets more complicated with XML-RPC though! The successive XML-RPC call you describe provoke new transactions, surely you're aware of that? Whereas just calling a function of course doesn't. I'm aware of that. But ZOPE offers XML-RPC and as there is nothing in the documentation about such complex interactions. Also, I was directly responding to what the previous poster had written. Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
Little bit tricky to try out as testers need to guess what all the missing code is. Any standard persistent ZOPE product wrapped around this will do. These are the only methods in a ZOPE product that inherits from Item, Persistent, RoleManager and Implicit. Also, for this kind of code demonstration, rather than directions for commenting/uncommenting and relying on the tester to restart the server between trails, provide different methods or even different classes. If I did that, people would say somethings wrong with your testing and they would have to do a line-by-line comparison and still have room to doubt my statement. But there is no extra transactional framework for XML-RPC clients (which your example has). Or for that matter acting as an XML-RPC server nested within some external transaction (which your example has). I was initially talking about a more complex situation that has been gradually simplified. ZOPE should be able to act as an XML-RPC client to the outside world. As to me not understanding what you all are saying: I believe I understand, I know that theoretically - from a merely technical viewpoint, it works, I just look at it from a different angle. Of course you have to know a framework and its limitations, but this error I stumbled upon strikes me as really complex (even though you keep repeating it's very simple if you just acknowledge xyz), for instance because the docs aren't perfect and say that You must explicitly signal any changes made to mutable attributes (such as instances, lists, and dictionaries) or use persistent versions of mutable objects, like ZODB.PersistentMapping (see below for more information on PersistentMapping.) - the _first_ option being mutable attributes! Also, there is no below. I believe you when you say that it is really very simple and I shouldn't have to worry if I follow the right principles, that you then go on to state (principles that aren't really that explicit anywhere - such as don't use XML-RPC to talk to ZOPE from ZOPE and don't use mutable subobjects at all). However, this is a further bit of distance between a ZOPE user and the Python he knows, and it also isn't as true for complex situations with complex requirements that I could probably just jot down in dumber frameworks such as RoR or Django or TurboGears. Because I know without having to check myself where I am designing Data, I explicitly _make_ changes (to the DB) and am thus very aware of where complex interactions might occur etc. This is probably one of those cases where no one is really right because a mixture of viewpoints is involved, I feel a bit as if we were talking about wether Lisp is better than Smalltalk. However, even if it is only the docs that are lacking I think it would be sensible to acknowledge that as a problem. It obviously was a problem for me, as of course was the complexity of my setup and several other factors. I am not an inexperienced programmer, so I would think that just because other people rarely stumble upon it it is not an insignificant problem. Imagine designing a large system based on some only marginally false assumptions about ZOPE transactions, persistence and XML-RPC interaction, and then running into this in a key component. Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! In Zope, it's just the whole object that's tainted. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. This had never occured to me as a _real_ problem before. Of course, if you just create self contained code on a small scale that doesn't talk to other programs on the web, you'll likely not run into any great problems because of this. Ole 2005/12/17, Lennart Regebro [EMAIL PROTECTED]: On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: It's not about the threads or processes being tied up and waiting, it's about the transaction breaking: because the internal call (the one from the second server back to the first) changes the object on the first server, and thus when the first server checks wether the object has changed after the transaction should close (during the last return), it finds that indeed it has, and before it could write to it, so it raises a conflict error invariably. This is still not a problem that has anything to do with Zope or persistenace, but it is quite simply just a conflict error. It will happen anywhere you do things like this. It will also only happen when you, in the processor of modifying an object, calls a method on another server, which, before that call finishes, makes a call back and modifies the *same* object. I can't currently dream up any scenario where this happens, but I'm happy that Zope raises an error when it does. A system that does NOT raise an error in this situation is broken. If you get problems like this, you need to make changes to the software so that this does not happen. The right way to do that depends on your application. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! It will not happen i Zope in this case either. No. It does happen, and it _did_ happen in my original problem. Zope doesn't even care if anything actually changes, it just considers an object changed that set self._p_changed=1. In Zope, it's just the whole object that's tainted. You just said different sets of data. That reasonably must mean different objects, unless you envision having huge objects with only marginally connected sets of data all stored as attributes. And then you have other problems. :-) No. An object usually binds together different sets of data (as in the above example - it has several fields, and that is true for almost any given object). What you are saying is don't program the ZOPE way, and it would eventually lead to the conclusion that your product classes should not have any persistent data, which is the conclusion I have come to. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. Eh, no they aren't. Please don't just claim stuff. ZOPE has persistent classes. Persistent classes store data that in ordinary programs would not survive as long. In ordinary systems, you would have to find a way to store the data and retrieve it, thus having a model that isn't implicit and entangled with your code. Of course, you could do the same in ZOPE, but I addressed that above, and you could mess up ordinary code, but I think we're agreed that it is not something you should aim for (and I think I have made it clear why I do not believe it's as easy to mess up generic Python code in this way). Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. This is wrong IMHO. dict and list are just columns of the same tuple if you speak RDBMS. And there are very few (if any?) databases which do locks only per column. In RDBMS you distribute in different tables to avoid such (e.g. normalize) in ZODB, you just make subclasses of Persistent for your subobjects. (Attributes) I'm not saying that it absolutely can't be done, it is just very difficult to do it right from the start because most of time you are not even aware you are fiddling with the data model. This of course isn't - I stressed that before - a problem for small scale development. But if you do more complex stuff with ZOPE it's a bit like going back to C - most of the mistakes in your design don't come back to you until much later. However, unlike C, ZOPE is very high level, and the problems stem from too much implicitness and too little separation of said data and code. When you design your model, you know that you are designing data and you handle those data as data explicitly. When you add a field to your class, you have to explicitly check yourself. And of course you could now answer You should be doing that anyway and that nothing hppens in perfectly designed code etc., but that's just not how it really works. You should be able to design stuff incrementally with a little experimentation along the way without constantly impending danger of it all crashing down on you. That's how Python works, and RoR etc. In ZOPE, we're back to the temptation to just stuff a bunch of data into my object. And it's not even obvious that this is a problem, because everything is so tightly interdependent. It's exactly what Python usually avoids (explicit is better than implicit). Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Zope Persistence (was: XML-RPC within ZOPE)
Thanks; this is a problem we are well aware of. Our solution is to increase the amount of workers, obviously. However, I'm increasingly getting a feeling that for a rather big range of unlikely situations that are nonetheless to be expected, Zope doesn't work _at all_. In a WebServices setting, situations like the one I described, with one server calling back to another server within a call from that latter server and both not knowing anything about the implementation of the other, it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them for persistent objects that actually _do_ change state (unlike mine). The solution is to not have state in your objects, and thus lose instantly most of what Zope is. However, as I see it, the problem is that what Zope actually _is_ (i.e. mostly the ZODB) is an unhealthy way of coupling data and implementation (which is _exactly_ why my implementation didn't work immediately). This of course comes from its origins in TTW development where there wouldn't actually have been many user made products. Please tell me if I'm wrong with my assumption above, and why. I'm not trying to be inflamatory, this just has me really worried. Ole 2005/12/15, Dieter Maurer [EMAIL PROTECTED]: Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100: Is it at all impossible to use XML-RPC _within_ a ZOPE architecture? In principle yes. Be careful however: it is easy to introduce deadlocks! When during request processing you call back into the same Zope via XML-RPC, the calling out request will not complete until the XML-RPC returns a result (this always holds for calls, XML-RPC or other, to an external or internal server). Zope has a limited amount of workers (the default is 4) able to execute requests. If there are no free workers, requests have to wait for one. Now imagine that as many requests arrive as there are workers and each of them wants to perform an XML-RPC against the same Zope. Then you have a deadlock: none of the XML-RPC requests will finish, because there are no free workers. An no worker will ever become free again, because each of them waits for its XML-RPC to finish. Therefore, you should directly call internal resources (rather than use XML-RPC). -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
Thanks, I will definitely look into that for my immediate problems. Ole 2005/12/16, Michael Haubenwallner [EMAIL PROTECTED]: Jan-Ole Esleben wrote: Thanks; this is a problem we are well aware of. Our solution is to increase the amount of workers, obviously. However, I'm increasingly getting a feeling that for a rather big range of unlikely situations that are nonetheless to be expected, Zope doesn't work _at all_. In a WebServices setting, situations like the one I described, with one server calling back to another server within a call from that latter server and both not knowing anything about the implementation of the other, it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them for persistent objects that actually _do_ change state (unlike mine). The solution is to not have state in your objects, and thus lose instantly most of what Zope is. However, as I see it, the problem is that what Zope actually _is_ (i.e. mostly the ZODB) is an unhealthy way of coupling data and implementation (which is _exactly_ why my implementation didn't work immediately). This of course comes from its origins in TTW development where there wouldn't actually have been many user made products. Please tell me if I'm wrong with my assumption above, and why. I'm not trying to be inflamatory, this just has me really worried. Ole You could try XMLRPCMethod. It creates its own worker thread and has a configurable timeout. Michael [1] http://www.zope.org/Members/EIONET/XMLRPC -- http://zope.org/Members/d2m http://planetzope.org ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
I don't understand the problem. How is using XML-RPC incompatible with persistence? What are you trying to exclude? I'm sorry, but I don't understand _that_ question. What am I trying to _exclude_? XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC (on a ZOPE server) and ZOPE persistence are, to the extent described by others in this thread, not by me. I just described a couple more cases (and specifically one case) where it is bad that things are this way (and cannot be solved by better design). My point is: this doesn't happen _within_ single programs, but everywhere there is even the slightest bit of communication there is a chance of it happening. Ole - C On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote: Thanks; this is a problem we are well aware of. Our solution is to increase the amount of workers, obviously. However, I'm increasingly getting a feeling that for a rather big range of unlikely situations that are nonetheless to be expected, Zope doesn't work _at all_. In a WebServices setting, situations like the one I described, with one server calling back to another server within a call from that latter server and both not knowing anything about the implementation of the other, it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them for persistent objects that actually _do_ change state (unlike mine). The solution is to not have state in your objects, and thus lose instantly most of what Zope is. However, as I see it, the problem is that what Zope actually _is_ (i.e. mostly the ZODB) is an unhealthy way of coupling data and implementation (which is _exactly_ why my implementation didn't work immediately). This of course comes from its origins in TTW development where there wouldn't actually have been many user made products. Please tell me if I'm wrong with my assumption above, and why. I'm not trying to be inflamatory, this just has me really worried. Ole 2005/12/15, Dieter Maurer [EMAIL PROTECTED]: Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100: Is it at all impossible to use XML-RPC _within_ a ZOPE architecture? In principle yes. Be careful however: it is easy to introduce deadlocks! When during request processing you call back into the same Zope via XML-RPC, the calling out request will not complete until the XML-RPC returns a result (this always holds for calls, XML-RPC or other, to an external or internal server). Zope has a limited amount of workers (the default is 4) able to execute requests. If there are no free workers, requests have to wait for one. Now imagine that as many requests arrive as there are workers and each of them wants to perform an XML-RPC against the same Zope. Then you have a deadlock: none of the XML-RPC requests will finish, because there are no free workers. An no worker will ever become free again, because each of them waits for its XML-RPC to finish. Therefore, you should directly call internal resources (rather than use XML-RPC). -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
I don't understand the problem. How is using XML-RPC incompatible with persistence? What are you trying to exclude? I'm sorry, but I don't understand _that_ question. What am I trying to _exclude_? You said: it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them That's probably an idiomatic error on my part, sorry. I meant avoid (in German, it's the same word). AFAICT, people have told you to not use XML-RPC here and when you said it was not possible to avoid the use of XML-RPC, they provided suggestion about how to accomplish what you wanted anyway. So I'm not sure what the exact problem is. The problem is a different one now, and I was referring to the _reasons_ people had for telling me not to use XML-RPC. Part of the problem I have now is that no application on the web is isolated from others, and that ZOPE specifically _comes_ with XML-RPC capabilities on the server's part. My point is: this doesn't happen _within_ single programs, but everywhere there is even the slightest bit of communication there is a chance of it happening. The chance of what happening, sorry? I'm still trying to understand the problem. The only problem that was noted so far was a deadlock potential by Dieter which presumed you were doing XML-RPC requests to the same system which accepts them. This is an unusual thing to do; it wouldn't happen under normal circumstances. The problem setup is this; I explained it above, but it this has become a long thread: I write a ZOPE product. I want to make use of other software on the internet and the services that software provides. So I use the methods exposed by that software via SOAP, XML-RPC, whatever. One of those methods actually calls my product back, maybe because the developer has learned that my product itself exposes some (or all) of its functionality via XML-RPC. If this is all inside one call, which I can't avoid explicitly as the developer of just my product, I have a broken transaction on my hands that isn't easy to fix (and maybe impossible). This holds true for the whole product, even if the method called by the second server changed some completely unrelated data. I hope that clears it up a little. Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
It's not about the threads or processes being tied up and waiting, it's about the transaction breaking: because the internal call (the one from the second server back to the first) changes the object on the first server, and thus when the first server checks wether the object has changed after the transaction should close (during the last return), it finds that indeed it has, and before it could write to it, so it raises a conflict error invariably. Ole 2005/12/17, Chris McDonough [EMAIL PROTECTED]: The problem setup is this; I explained it above, but it this has become a long thread: I write a ZOPE product. I want to make use of other software on the internet and the services that software provides. So I use the methods exposed by that software via SOAP, XML-RPC, whatever. One of those methods actually calls my product back, maybe because the developer has learned that my product itself exposes some (or all) of its functionality via XML-RPC. If this is all inside one call, which I can't avoid explicitly as the developer of just my product, I have a broken transaction on my hands that isn't easy to fix (and maybe impossible). This holds true for the whole product, even if the method called by the second server changed some completely unrelated data. I see what you're saying, but how is this specific to Zope? If you write a Perl program and expose it via mod_perl on Apache, and the program calls out to a service that calls back in to the mod_perl program (no matter how broken of a pattern this was), wouldn't the Apache process that was waiting on data be tied up in the same way? - C ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] XML-RPC within ZOPE
The problem is that it isn't my design, and the design is part of a contract. I can't really do anything about that (the major problem is that there will be SOAP components that might even need to be transparently integrated - which completely excludes ZEO). I tried doing my own commits, but it doesn't work, it just bombs earlier (no matter where I do them). I really don't know why, my only guess is that something about the transaction management breaks terribly when you go back and forth between objects without them being able to track it. Only I cannot figure out what. It is not possible to do _really_ explicit transaction management with ZODB, is it? Ole 2005/12/12, Alan Milligan [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan-Ole Esleben wrote: OK, the following is the case: The setup is for functions dispatching either locally or via XML-RPC. At the moment, the mechanism I use is to detect locality is flawed and thus doesn't work well. So I have local XML-RPC calls where I could have global ones. But. 1. I need that possibility for testing the XML-RPC setup. I cannot set up multiple instances for every cheap test. At least I shouldn't have to. The very important reason, however, is: 2. This is a generic call dispatcher. It is used, for example, for object name resolution in a widely deployed system. So, what could happen and couldn't happen locally is this: Zope isn't CORBA. ZEO is the correct way to scale/cluster Zope's. 1. Server1 dispatcher calls, via XML-RPC, Server2. 2. Server2 dispatcher calls Server1, which does something locally (same communication management object as the dispatcher, maybe another local call) and then returns This is the same problem spread out over two servers, where locality isn't possible anymore. The call from Server1 to Server2 must be made via XML-RPC and I cannot exclude Server2 calling Server1 back. If you really must architect your solution this way, then you are going to have to do your own transaction management. Your 'local' calls need to do explicit commit() calls and you're going to have to reread 'tainted' objects. Again, it will take you half an hour to modify your design instead of half a year to get all the bugs out of your implementation. Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDnN2ACfroLk4EZpkRAkQ7AJ4rTWpmldRq1GoPGIV8r0CT7+VPJwCZAbKB 5PBuLd5sJgh7QZe1ey8lZ9g= =3TrG -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [ZOPE] XML-RPC within ZOPE
Chris: the errors I get are always ConflictErrors without any usable tracebacks. I would like to give more information, but it really is very complex when you go a little deeper and would probably not be useful. I'll try to describe it a little better anyway: I have an Object that offers an interface for dispatching methods. It does so by deciding wether the method's object is on the local server or not, and depending on that, calls it via XML-RPC or via the ZOPE context (self). A remote ZOPE server cannot be part of a ZEO backend because there need to be several (hundred) self sustained servers that can act on their own when the connection to the others fails (which is likely rather than possible). But, as I just realised - in an internet context, isn't it possible that something like this could happen without even being part of a design? One ZOPE server's object, say, LibraryManager, calls an object in another ZOPE server, say UniversityLibrary, via XML-RPC (because it doesn't even know it's ZOPE). It asks it for a book. The University Library doesn't have it, but it has a service that looks in all the libraries it knows and returns any found occurences. Thus, at some point during that call, it asks the first server's LibraryManager about the book - again, not even knowing that it is a ZOPE server, via XML-RPC. Should this work, and where does it differ from what I'm doing? The problem is that it isn't my design, and the design is part of a contract. I can't really do anything about that (the major problem is that there will be SOAP components that might even need to be transparently integrated - which completely excludes ZEO). Why do you think that? ZEO is simply a single point of persistence for a group of Zope Application Servers. But what if I don't know which components are ZOPE, and components can be transparently exchanged? Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] XML-RPC within ZOPE
Hi! Is it at all impossible to use XML-RPC _within_ a ZOPE architecture? What I mean is: I have a nested call structure: 1. Python script calls a method from a ZODB object 2. That method calls a Python module function 3. That module function dispatches an XML-RPC call to the same ZODB object called in step 1 4. This last call, which is rather complex, returns, and all the calls leading up to it return, sometimes doing some minor work When I use the same code _without_ any XML-RPC (the Zope server's self instead of the XML-RPC server object for that server), it works just fine. When I use XML-RPC, I get a ConflictError during the final return (from step 1), and I get it if I commit manually beforehand, so it must be the commit triggering it. The tricky thing is: nothing in my ZODB changes. I have several mutable _arguments_ that are passed on, but they are not default arguments and they don't get written to the ZODB. Is what I'm trying to do impossible for some reason? Or can I just make the whole call take place outside any transactions? Thanks in advance for any pointers, I'm really a little desparate at this point. Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] XML-RPC within ZOPE
It really *is* in your interests to ensure a single request completes all your functional requirements ;) That's not possible unfortunately. The design of the system is rather complex, and unalterable in this respect. However, it is not true that it is usually possible to fulfil this requirement. What of programs running on an operating system that call other programs via that operating system? Given that that is a requirement that needs to be met, do I have any options? Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] XML-RPC within ZOPE
OK, the following is the case: The setup is for functions dispatching either locally or via XML-RPC. At the moment, the mechanism I use is to detect locality is flawed and thus doesn't work well. So I have local XML-RPC calls where I could have global ones. But. 1. I need that possibility for testing the XML-RPC setup. I cannot set up multiple instances for every cheap test. At least I shouldn't have to. The very important reason, however, is: 2. This is a generic call dispatcher. It is used, for example, for object name resolution in a widely deployed system. So, what could happen and couldn't happen locally is this: 1. Server1 dispatcher calls, via XML-RPC, Server2. 2. Server2 dispatcher calls Server1, which does something locally (same communication management object as the dispatcher, maybe another local call) and then returns This is the same problem spread out over two servers, where locality isn't possible anymore. The call from Server1 to Server2 must be made via XML-RPC and I cannot exclude Server2 calling Server1 back. Does this make it a little more of a real problem? Ole 2005/12/12, Alan Milligan [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan-Ole Esleben wrote: It really *is* in your interests to ensure a single request completes all your functional requirements ;) That's not possible unfortunately. The design of the system is rather complex, and unalterable in this respect. However, it is not true that it is usually possible to fulfil this requirement. What of programs running on an operating system that call other programs via that operating system? I don't believe you. You have a client application calling your Zope server's bla() function. It can do this either by HTTP or XML-RPC by choosing the appropriate Content-Type. You've chosen to implement this interface by making other XML-RPC calls to the same server to complete the task. This is both unnecessary and bad. Unnecessary because you're doing an RPC when you've got all you need in local memory. This is bad because you're introducing the additional overhead of setting up said RPC. Worse, you're now responsible for your own transaction management because you've split the task across multiple ZODB connections. You need to think about the *correct* way to write your bla() function. In doing this, you want to be able to take advantage of the automatic rollback facilities of Zope by keeping all of this in one transaction, which will also avoid your initial problem of conflict errors. Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDnNZcCfroLk4EZpkRArTDAJ96TGwDy047D09jkmRNbGyD7e+3QgCg0aNZ lLo0znXi4qvXr5j4SseH2k8= =hu4V -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZASync method calls
Thanks for the suggestion; it helped in part: I can now get it to work basically (the asynchronous job hadn't run at all in the background, while now - from my own debugging output - I can see that it does). However, the instance variable doesn't change until the caller of the asynchronous method has finished - it _is_ different afterwards though, it seems like the caller doesn't check for a change; is there a way to force that? Ole 2005/8/23, Jonathan [EMAIL PROTECTED]: - Original Message - From: Jan-Ole Esleben [EMAIL PROTECTED] I'm having a really complicated problem that I don't know how to put into words properly, because I'm really vague on what's causing it and the setup is highly involved; I would be _really_ glad if someone could help me out with this: I have a ZOPE instance (connected to a ZEO server) running a custom method call wrapper that decides (based on the method's arguments) to run a method asynchronously using zasync (as well as some other stuff that I think isn't important in the context of my problem). All this has been tested. For various reasons, the method call's path is approximately as follows: 0. Method call using a generic Python method 1. Python code - resolves the method's location and name using ZOPE methods 2. Method dispatcher (called via ZOPE): dispatches synchronously or asynchronously, using zasync, zope_exec and putSessionCall; the method called is again a ZOPE method that calls the final method as another ZOPE method The apparent massive indirection cannot be avoided (for rather complicated reasons). Everything is supposed to be highly generic. My problem is this: if I use a test method that dispatches such an asynchronous method that is supposed to change an instance variable (the class is persistent) and run for ten seconds, then wait for fourteen seconds and see if the method has run (check the instance variable) synchronously (while the asynchronous method is supposed to work in the background), I find the variable unchanged; further checks (using print statements) confirm that the asynchronous method indeed doesn't run until my assertion fails, even if I give it a lot of time. If I disconnect both - run the long running method asynchronously, then run (via ZOPE directly, not from within the same method call) a synchronous method that waits for fourteen seconds and checks the variable, the asynchronous call works just fine (even though both run alongsinde for a time). It isn't the number of threads available to the zserver, I've increased that and nothing has changed. Manual tests of asynchronous methods also don't show anything wrong with my zasync setup. I can only assume that the asynchronous method is _started_ only _after_ the caller has finished. Is there a reason for that, and can I circumvent it? Or am I completely wrong and something else isn't working? I'm on Windows XP SP2, ZOPE 2.7.6, Python 2.3.5 with Twisted installed. Is it possible that your asynchronous routine is not committing the transaction? ie. If zope considers the async routine to be part of the current 'session' then the variable the async routine is updating will not be changed until the current session is completed and zope commits the transaction (so any checks of the variable during the current session will not see any changes to the variable). To see if this is the case you could add a get_transaction().commit() statement in your code after you change the variable's contents. hth Jonathan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] ZASync method calls
Hi! I'm having a really complicated problem that I don't know how to put into words properly, because I'm really vague on what's causing it and the setup is highly involved; I would be _really_ glad if someone could help me out with this: I have a ZOPE instance (connected to a ZEO server) running a custom method call wrapper that decides (based on the method's arguments) to run a method asynchronously using zasync (as well as some other stuff that I think isn't important in the context of my problem). All this has been tested. For various reasons, the method call's path is approximately as follows: 0. Method call using a generic Python method 1. Python code - resolves the method's location and name using ZOPE methods 2. Method dispatcher (called via ZOPE): dispatches synchronously or asynchronously, using zasync, zope_exec and putSessionCall; the method called is again a ZOPE method that calls the final method as another ZOPE method The apparent massive indirection cannot be avoided (for rather complicated reasons). Everything is supposed to be highly generic. My problem is this: if I use a test method that dispatches such an asynchronous method that is supposed to change an instance variable (the class is persistent) and run for ten seconds, then wait for fourteen seconds and see if the method has run (check the instance variable) synchronously (while the asynchronous method is supposed to work in the background), I find the variable unchanged; further checks (using print statements) confirm that the asynchronous method indeed doesn't run until my assertion fails, even if I give it a lot of time. If I disconnect both - run the long running method asynchronously, then run (via ZOPE directly, not from within the same method call) a synchronous method that waits for fourteen seconds and checks the variable, the asynchronous call works just fine (even though both run alongsinde for a time). It isn't the number of threads available to the zserver, I've increased that and nothing has changed. Manual tests of asynchronous methods also don't show anything wrong with my zasync setup. I can only assume that the asynchronous method is _started_ only _after_ the caller has finished. Is there a reason for that, and can I circumvent it? Or am I completely wrong and something else isn't working? I'm on Windows XP SP2, ZOPE 2.7.6, Python 2.3.5 with Twisted installed. TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Metaclasses in ZOPE Products
Hi! What do I need to do to derive a new base class for my products from item that defines its own meta class? There's a whole mess of code in the Zope source code that deals with meta classes, but nothing I can actually identify as the thing to do. I am deriving from SimpleItem at the moment. Currently, I use a meta class derived from type, but this doesn't work: File E:\Python23\lib\fliwas\ccitem.py, line 54, in ? class CCItem(SimpleItem): File E:\Python23\lib\fliwas\ccmethods.py, line 38, in __new__ return type.__new__(cls, name, bases, classdict) TypeError: metaclass conflict: the metaclass of a derived class must be a (non-s trict) subclass of the metaclasses of all its bases I'm guessing that using a certain base class for my meta class should work, but the documentation doesn't say (as far as I can find out). TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Follow-up to aq_parent(aq_inner(self))-question
Hi! How can I get the product's path while instantiating it? Shouldn't this information exist somewhere? aq_parent(aq_inner(self)) returns None, which isn't totally unexpected since __init__ isn't strictly a Zope method and thus doesn't necessarily have a Zope method's context. (I need, from the __init__ method of a product, to find out its instantiation path in the ZODB.) TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Getting a methods parent (in a product)
Hi! How can I get a Product instance's _actual_ parent when one of its methods is called? (In other ways: how can I find out, from an instance, where that instance is located without falling prey to acquisition in Zope 2?) TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting a methods parent (in a product)
Thanks a lot, I'll try that. Ole 2005/7/22, Jens Vagelpohl [EMAIL PROTECTED]: On 22 Jul 2005, at 18:48, Jan-Ole Esleben wrote: Hi! How can I get a Product instance's _actual_ parent when one of its methods is called? (In other ways: how can I find out, from an instance, where that instance is located without falling prey to acquisition in Zope 2?) from Acquisition import aq_inner, aq_parent parent = aq_parent(aq_inner(self)) This will return the true container the instance is set in, not just the acquisition parent. jens ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Change user (pythonic)
Hi! I can't seem to figure out from the documentation or through web research how it is possible to change the currently logged in user pythonically (e.g. in an fs product or extension method). Can anybody give me a hint? TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Timeout?
Hi! Is there a way to have a ZOPE method (called, for example, via a TALES expression) time out after a specific (changeable!) amount of time? TIA, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting information about current method
Well, thanks anyway for your suggestions; I hope someone else can suggest something; my intuition is that it isn't possible (without going really low level), and that would really be bad... Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: It's an application instance wrapped in a list; it seems to be identical to self, actually - self.REQUEST['URL'] and self.REQUEST.PARENTS[0].REQUEST['URL'] are the same. However, the two REQUESTs are not the identical object (== returns False). Then I don't know. (The application instance is none other than zope itself. ) I can honestly not think of a way to extract this information. I've even tried setting up a simple example method and I couldn't get hold of the zodb name of the external method that is called. Perhaps Andreas or Dieter can help us here?? Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: No, I'm sorry; I only get system paths. And what about REQUEST.PARENTS? (or is that just the http request) Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: Unforunately, this just gives me the pythonic path to the method; what I need for a TALES expression is the ZOPE path - i.e. what I get from the stack frame is ... E:\zope\Extensions\req.py ... but what I need is ... http://localhost:8080/ReqTest ... Ok, maybe inspect.stack()[1] was the wrong one. Can't remember nor test it for you but try any of the others in that list. Eg. inspect.stack()[0] or inspect.stack()[2] You can maybe find something by going through REQUEST.PARENTS Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: Then, in your External method, try:: import inspect print inspect.stack()[1] On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I want to know the name (and path) of the _External Method_ from inside it. What I _can_ get is the name of the DTML method. I want to build generic scaffolding code for functions that conditionally redispatch as asynchronous calls (via ZASync); that part, however, isn't a problem at all - everything works fine as long as I use an HTTP request directly and redispatch with information from the REQUEST. The problem is that I need a TALES expression to call the function again (asynchronously this time), and for that I need the ZOPE path to it. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. I don't get it. Do you want to know the name of the DTML method from inside the External method? Perhaps I'll be able to help if you tell us more about the intention of this code. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
[Zope] Getting information about current method
Hi! I am new to this list and rather new to Zope, so maybe this is a stupid question; unfortunately I haven't been able to find an answer to it anywhere: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting information about current method
I want to know the name (and path) of the _External Method_ from inside it. What I _can_ get is the name of the DTML method. I want to build generic scaffolding code for functions that conditionally redispatch as asynchronous calls (via ZASync); that part, however, isn't a problem at all - everything works fine as long as I use an HTTP request directly and redispatch with information from the REQUEST. The problem is that I need a TALES expression to call the function again (asynchronously this time), and for that I need the ZOPE path to it. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. I don't get it. Do you want to know the name of the DTML method from inside the External method? Perhaps I'll be able to help if you tell us more about the intention of this code. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting information about current method
Unforunately, this just gives me the pythonic path to the method; what I need for a TALES expression is the ZOPE path - i.e. what I get from the stack frame is ... E:\zope\Extensions\req.py ... but what I need is ... http://localhost:8080/ReqTest ... Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: Then, in your External method, try:: import inspect print inspect.stack()[1] On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I want to know the name (and path) of the _External Method_ from inside it. What I _can_ get is the name of the DTML method. I want to build generic scaffolding code for functions that conditionally redispatch as asynchronous calls (via ZASync); that part, however, isn't a problem at all - everything works fine as long as I use an HTTP request directly and redispatch with information from the REQUEST. The problem is that I need a TALES expression to call the function again (asynchronously this time), and for that I need the ZOPE path to it. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. I don't get it. Do you want to know the name of the DTML method from inside the External method? Perhaps I'll be able to help if you tell us more about the intention of this code. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting information about current method
No, I'm sorry; I only get system paths. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: Unforunately, this just gives me the pythonic path to the method; what I need for a TALES expression is the ZOPE path - i.e. what I get from the stack frame is ... E:\zope\Extensions\req.py ... but what I need is ... http://localhost:8080/ReqTest ... Ok, maybe inspect.stack()[1] was the wrong one. Can't remember nor test it for you but try any of the others in that list. Eg. inspect.stack()[0] or inspect.stack()[2] You can maybe find something by going through REQUEST.PARENTS Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: Then, in your External method, try:: import inspect print inspect.stack()[1] On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I want to know the name (and path) of the _External Method_ from inside it. What I _can_ get is the name of the DTML method. I want to build generic scaffolding code for functions that conditionally redispatch as asynchronous calls (via ZASync); that part, however, isn't a problem at all - everything works fine as long as I use an HTTP request directly and redispatch with information from the REQUEST. The problem is that I need a TALES expression to call the function again (asynchronously this time), and for that I need the ZOPE path to it. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. I don't get it. Do you want to know the name of the DTML method from inside the External method? Perhaps I'll be able to help if you tell us more about the intention of this code. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Getting information about current method
It's an application instance wrapped in a list; it seems to be identical to self, actually - self.REQUEST['URL'] and self.REQUEST.PARENTS[0].REQUEST['URL'] are the same. However, the two REQUESTs are not the identical object (== returns False). Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: No, I'm sorry; I only get system paths. And what about REQUEST.PARENTS? (or is that just the http request) Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: Unforunately, this just gives me the pythonic path to the method; what I need for a TALES expression is the ZOPE path - i.e. what I get from the stack frame is ... E:\zope\Extensions\req.py ... but what I need is ... http://localhost:8080/ReqTest ... Ok, maybe inspect.stack()[1] was the wrong one. Can't remember nor test it for you but try any of the others in that list. Eg. inspect.stack()[0] or inspect.stack()[2] You can maybe find something by going through REQUEST.PARENTS Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: Then, in your External method, try:: import inspect print inspect.stack()[1] On 6/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I want to know the name (and path) of the _External Method_ from inside it. What I _can_ get is the name of the DTML method. I want to build generic scaffolding code for functions that conditionally redispatch as asynchronous calls (via ZASync); that part, however, isn't a problem at all - everything works fine as long as I use an HTTP request directly and redispatch with information from the REQUEST. The problem is that I need a TALES expression to call the function again (asynchronously this time), and for that I need the ZOPE path to it. Ole 2005/6/17, Peter Bengtsson [EMAIL PROTECTED]: is there a generic way to find out from Python code which method has been called (in other words: find out where the current method is located in the ZOPE hierarchy and what its name is)? If I call an External Method via a DTML method, of course the REQUEST object contains the path to the DTML method because the External Method hasn't been called via HTTP. I haven't been able to figure out any other way of getting this information. I don't get it. Do you want to know the name of the DTML method from inside the External method? Perhaps I'll be able to help if you tell us more about the intention of this code. Thanks in advance, Ole ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
