On Wednesday 05 Jun 2002 4:32 am, William Trenker wrote:
And I
suspect it is probably asking a bit too much of one Celeron 400 with
Windows 98 to have all that running. What do you think?
One Zope using a ZEO server on the same machine is going to take only
marginally more resources than
From: William Trenker [EMAIL PROTECTED]
I've read the various tutorials and have successfully used Zope with the
Python debugger. But, of course, I can't have my production Zope running
and the debugger running at the same time unless I get Zeo going. But is
there another way? Is it
Erik A. Dahl wrote:
Ok I need to override __getattr__ in one of my product classes. I'm
sure this is killing acquisition
yes
but not sure about the persistence
stuff (I think this is working).
it will still work
Is there a way to make this work?
yes
Here is what I'm doing:
If your __getattr__ fails to find what it wants, it should raise an
AttributeError. This will give the ball back to the acquisition
machinery.
Thusly:
def __getattr__(self, name):
if name = 'foo':
return self.foo()
raise AttributeError, name
hth,
-Casey
On Tue, 2002-06-04 at
You might be able to use the medusa monitor client.
(ZServer/medusa/monitor_client.py). This requires that you have an access
file in your Zope's software home.
- Original Message -
From: William Trenker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 11:32 PM
How about making __setattr__ work ? I keep having Acquisition tell me that it
cannot find the Acquisition.Acquired properties.
Nic
On Wednesday 05 June 2002 09:21 am, Casey Duncan wrote:
If your __getattr__ fails to find what it wants, it should raise an
AttributeError. This will give the
Given the following code:
I can see why access to self.thing fails in Inner::__setattr__, but the
question is how do I do that -- can I not use __setattr__ and have to use a
setAttr that is accessed via O.I.setAttr('help','me rhonda') ?
Nic
import ExtensionClass, Acquisition
class
AFAIK acquisition bows out quietly during __getattr__, __setattr__.
You'll have to find another way to pass in the thing values before
__setattr__ gets called.
Maybe try an explicit self.aq_acquire('thing'). Maybe that would work.
-Casey
On Wed, 2002-06-05 at 09:33, Nicholas Henke wrote:
Nicholas Henke (by way of Nicholas Henke ) wrote:
Given the following code:
I can see why access to self.thing fails in Inner::__setattr__, but the
question is how do I do that -- can I not use __setattr__ and have to use a
setAttr that is accessed via O.I.setAttr('help','me rhonda') ?
Lennart Regebro [EMAIL PROTECTED] wrote:
From: R. David Murray [EMAIL PROTECTED]
Well, since as far as I know there hasn't been any real Z3 work on
groups, and not much discussion (recently, at least), I suspect
having Florent get in there and push is the best way to get Z3 and
Z2 in
On Tuesday 04 June 2002 10:24 pm, Robert Rottermann wrote:
I agree with you.
And they depend on CMF only very ligthly. So taking them out of CMF should
be easy.
indeed it was.
http://www.zope.org/Members/k_vertigo/Products/FileSystemSite
i don't have the unit tests ported over, but they are
On Wed, Jun 05, 2002 at 05:15:10PM +, Florent Guillaume wrote:
Jim Penny [EMAIL PROTECTED] wrote:
Is there a safe way to handle multiple monkeypatches?
Without an existing framework (I haven't looked at Adrian's PatchKit),
it's the same old problem as intercepting interrupts on good
Yep. This is a problem for me I'm trying to find something through
acquisition in my __setattr__. Self is totally unwrapped. Can anyone
think of a creative solution? aq_acquire doesn't help because self is
not a wrapped object. :( Can't pass in the object I want because the
whole point
Why rely on __setattr__? Why not just create a regular setter function
that can use acquisition instead of being clever?
-Casey
On Wed, 2002-06-05 at 15:24, Erik A. Dahl wrote:
Yep. This is a problem for me I'm trying to find something through
acquisition in my __setattr__. Self is
Hmm there is a patch for the PatchKit that puts the ZMI in the ZODB, is that
what you need? :)
From the Doc String:-
Zope Management Interface Style Sheet Patch
== = = = =
The patch adds a ZStyleSheet to the root of your Zope
with its contents
PatchKit handles this for you (If you ask it to).
:)
Adrian...
--
Adrian Hungate
EMail: [EMAIL PROTECTED]
Web: http://www.haqa.co.uk
Computers are like air conditioners
-- they stop working properly if you open WINDOWS
- Original Message -
From: Florent Guillaume [EMAIL
On Wed, Jun 05, 2002 at 10:51:45PM +0100, Adrian Hungate wrote:
PatchKit handles this for you (If you ask it to).
:)
Adrian...
I am not sure that I understand. I need to be able to do a
cumulative monkey patch. Suppose that there were two independent
products which both modified
PatchKit allows the replacement of entire methods, with the ability to
backup the original when the first replacement is done - This means that the
patches are (Or at least can be) refreshable.
PatchKit does not allow for small changes to be made within a method (Such
as a DTML/HTML object) but
I found this post from Ted Skolnick but saw no follow-ups, and I am
having the same problems. Ted, did you get this resolved?
I have an external method that takes 3 params. After I restart Zope (
running on Linux ), I get the following error on my first call...
Error Type: TypeError
casey duncan put a fix into CVS for what you might be experiencing. it will
probably show up with the first 2.6 betas.
jens
On Wednesday, June 5, 2002, at 11:11 , Emile van Sebille wrote:
I found this post from Ted Skolnick but saw no follow-ups, and I am
having the same problems. Ted,
20 matches
Mail list logo
