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
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 -
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
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
]:
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
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
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
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 -
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 -
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
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
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.
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)
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
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
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
: 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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
30 matches
Mail list logo
