Hmm... ok, now I see what you are talking about, however, you are talking
about modifying a DTMLFile object - I am not sure of any reliable API (Or
even magic) that will allow that to happen in a "play nice with others" way.
Just for clarity's sake (For me if no-one else), what object type are you
wanting to change manage_main for?
I have to admit to not knowing zshell or external_editor well, but I have
seen mentions of ee making changes to the ZMI - I had assumed this was the
addition of tabs (And DTMLFiles), not the replacement of them. I take it I
was wrong in this assumption?
EMail: [EMAIL PROTECTED]
----- Original Message -----
From: "Jim Penny" <[EMAIL PROTECTED]>
To: "Adrian Hungate" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 14, 2002 3:34 PM
Subject: Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches
> On Wed, Aug 14, 2002 at 08:46:41AM +0100, Adrian Hungate wrote:
> > >
> > > Again, monkey patching doesn't modify source code, so I don't know
> > > what would be getting written into tmp.
> > >
> > > > Comments?
> > >
> > > Didn't someone else make a proposal (with code) to handle this?
> > > Was it PatchKit?
> > Yup, and it is more than a proposal, it is a full blown product (
> > http://www.zope.org/Members/haqa/PatchKit ) with some patches already in
> > (They can be removed if you wish).
> Nope... we have been down this path before. Note this what I need (see
> below on why) requires modification, and not simple replacement, of
> whatever code is currently running. As far as I can see, Patchkit does
> nothing to make this possible.
> The problem is that A) monkey patches may or may not
> have been applied before a given product sees anything, and B) there is
> no reasonable way to discover what (or even if) patches have been
> applied by other products.
> If you are going to go down the monkeypatch path, then there needs to be
> some way for other monkeypatchers to discover what you have done, so
> that they can decide if they can 1) extend your code to be compatible
> with theirs, 2) refuse to install their code, or 3) blow your
> pre-existing code away.
> Current monkeypatch code always does 3. Patchkit has, as far as I can
> tell no way to make 1 or 2 easier. It just makes it easier to blow
> other people's work away!
> Background: I am debian maintainer for zope-zshell. The debian release
> is currently a version behind. I have been holding off updating it
> because I would like the ZMI box. I cannot modify manage_main.py
> because it belongs to the zope package and the changes would be blown
> away on any upgrade of zope. I was starting to turn it into a python
> product, but zope-externaleditor has been packaged, and it monkeypatches
> manage_main. The naive thing to do would be to install it as a
> monkeypatch. But then, either I blow away externaleditor, or
> externaleditor blows away zshell, depending on the order in which zope
> installs products on startup. There are several other products that
> monkeypatch manage_main as well, building a nice mutual destruction
> Jim Penny
> PS: I would also like to hear general responses to Jerome's proposal.
> Clearly this was not an API, no arguments have been specified. But is
> there a general consensus that this is a reasonable thing to do?
> Please, if it isn't to late, could we make it a 2.6 thing?
> > There is a fledgling API, though I probably need to document it better,
> > some unit tests etc, but it is there, and it works (For me... YMMV).
> > > But yes, some "standard" would be helpful, possibly with supporting
> > > utilities, to allow multiple monkeypatches coexist, I think.
> > >
> > > On the other hand, in Zope3 you just change the zcml files...although
> > > I think there was a discusion of an analogous issue there (coexistence
> > > of multiple "modifications" to the same area) and I'm not sure
> > > a conclusion was reached (but I can't remember for sure).
> > >
> > Adrian...
> > --
> > Adrian Hungate
> > EMail: [EMAIL PROTECTED]
> > Web: http://www.haqa.co.uk
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -