Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Adrian Hungate


 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 it
(They can be removed if you wish).

There is a fledgling API, though I probably need to document it better, make
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]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Jim Penny

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 it
 (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 directly,
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
club.

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, make
 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]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Adrian Hungate

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?

Adrian...

--
Adrian Hungate
EMail: [EMAIL PROTECTED]
Web: http://www.haqa.co.uk

- 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
it
  (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
directly,
 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
 club.

 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,
make
  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]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Adrian Hungate

Hmm... that is not good. I can't see you getting an API to change a DTML
file. The only option would be to create the ObjectManager's contents page
from python, and people seem not to like doing that, but it would allow a
little more engineering to take place.

Hmmm...

It looks as though what is needed is fish-bowl proposal to redesign the way
ObjectManager handles and displays rows for specific object types - the
requirement being that this be third-party-pluggable (For want of a better
term). (No that was not me volunteering - too much on at the moment, sorry).

One question about zshell though, what is the box that is added left of the
add product pulldown? Is it something that ABSOLUTELY has to be on the
contents listing (i.e. something to do with creating or maintaining the
objects listed?). Could it be backdoor'd into all_meta_types so that it,
itself is listed in the pulldown, or could it have a ZMI tab of it's own
(Both of these are easier than live patching the DTML)?

Adrian...

--
Adrian Hungate
EMail: [EMAIL PROTECTED]
Web: http://www.haqa.co.uk

- Original Message -
From: Jim Penny [EMAIL PROTECTED]
To: Adrian Hungate [EMAIL PROTECTED]
Sent: Wednesday, August 14, 2002 4:26 PM
Subject: Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches


 On Wed, Aug 14, 2002 at 03:48:51PM +0100, Adrian Hungate wrote:
  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?

 yeah, externaleditor inserts icons into many rows of the name column.
 zshell want an extra text box to the left of the add product pulldown.
 There are other products that do similar things.  I think the Photo
 product modifies things in a similar manner to externaleditor.
 These are, I suspect, not even at the object stage.  You have to modify
 rows in a table.

 Jim



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Adrian Hungate

On Wed, 14 Aug 2002, Jim Penny wrote:

[Snip]

  It looks as though what is needed is fish-bowl proposal to redesign the way
  ObjectManager handles and displays rows for specific object types - the
  requirement being that this be third-party-pluggable (For want of a better
  term). (No that was not me volunteering - too much on at the moment, sorry).
 
  One question about zshell though, what is the box that is added left of the
  add product pulldown? Is it something that ABSOLUTELY has to be on the
  contents listing (i.e. something to do with creating or maintaining the
  objects listed?). Could it be backdoor'd into all_meta_types so that it,
  itself is listed in the pulldown, or could it have a ZMI tab of it's own
  (Both of these are easier than live patching the DTML)?
 
  Adrian...

 It needs a place to type a command, that is, it is a free form text box.
 That is, zshell gives zope a CLI.  Historically, you have had to click
 on something to get to the CLI.  If it is made part of the ZMI, then the
 CLI is part of every management window, with no extra work needed to use
 it.

 What is needed is to insert a form with a single textbox as element.

 This seems to be a hard problem.  Introducing monkeypatches, has, in my
 opinion made it harder, before people would have simply given up.

Hmm, the more you describe this, the less the ObjectManager's contents
view seems quite the right place for it. If the relationship to
the current ObjectManager is required, then what is the problem with a ZMI
tab (Titled zShell or Command Line or whatever). This could easily be
implimented, would survive upgrades, and (To me at least) would be a more
logical interface.

 Jim

 
  --
  Adrian Hungate
  EMail: [EMAIL PROTECTED]
  Web: http://www.haqa.co.uk


--
Adrian Hungate
EMail: [EMAIL PROTECTED]
Web: http://www.haqa.co.uk


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Jerome Alet

On Wed, Aug 14, 2002 at 05:08:21PM +0100, Adrian Hungate wrote:
 
 One question about zshell though, what is the box that is added left of the
 add product pulldown? Is it something that ABSOLUTELY has to be on the
 contents listing (i.e. something to do with creating or maintaining the
 objects listed?). Could it be backdoor'd into all_meta_types so that it,
 itself is listed in the pulldown, or could it have a ZMI tab of it's own
 (Both of these are easier than live patching the DTML)?

About ZShell : IF and ONLY if you want to use ZShell from the right
frame of the ZMI (manage_main) you currently have to modify manage_main
to put a text input field somewhere on it. Then running ZShell from there
applies ZShell commands to the current folderish object. (Of course you
can in any case use ZShell by pointing your web browser to it)

Of course ZShell could use a special tab, or another clever solution,
but IMHO this is really NOT the problem here.

The problem is not about ZShell, ExternalEditor, or any other Zope 
product, but if I understand correctly it is about extending, not
replacing, the Zope's main management interface. Jim please correct
me if I'm wrong.

That's why I proposed to add three loops in manage_main, to loop over
three different types of plugins. Each Zope product which wants to
extend the ZMI should register itself once as a ZMI plugin of 
three sorts :

- top ZMI plugin : displayed once at the top (ex : ZShell)
- line ZMI plugin : displayed once for each object 
  (ex : External Editor)
- bottom ZMI plugin : displayed once at the bottom
  (ex : xxx)
  
registering a ZMI plugin would be as simple as :

root.registerZMIPlugin(top|line|bottom, self) 

or :

root.registerTopZMIPlugin(self)
root.registerLineZMIPlugin(self)
root.registerBottomZMIPlugin(self)

self represents the object which wants to register as a ZMI
plugin. It would have to provide at least one of the
three methods :

TopZMIPlugin(self, obj)
LineZMIPlugin(self, obj)
BottomZMIPlugin(self, obj)

these three methods would have to render some html snippet, e.g. a 
form with a text input field for ZShell, or a nice icon with a link 
for External Editor. obj would be the object on which the method
applies, e.g. current folder, or current object in the object
listing.

This way manage_main could be rendered more powerful by just adding 
three dtml-in in it, and its aspect wouldn't even change in case
no ZMI plugin would be registered (which is the case with a base
Zope installation).

any comment ?

thx for reading

Jerome Alet

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-14 Thread Jerome Alet

On Wed, Aug 14, 2002 at 09:33:02PM +0200, Jerome Alet wrote:
   
 registering a ZMI plugin would be as simple as :
 
 root.registerZMIPlugin(top|line|bottom, self) 
 
 or :
 
 root.registerTopZMIPlugin(self)
 root.registerLineZMIPlugin(self)
 root.registerBottomZMIPlugin(self)
 
 self represents the object which wants to register as a ZMI
 plugin. 

I forgot to add that root in this case means any unique
Zope object which we are certain is always present (e.g. the
root object or the ControlPanel), which would register all 
plugins as its own properties and could list all plugins
(that's why the ControlPanel is a good idea, but I don't know
if it would support this functionnality easily).

hoping this gets clearer now

Jerome Alet

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread R. David Murray

On Tue, 13 Aug 2002, Jim Penny wrote:
 B)  If so, he makes whatever checks he can to determine if he can
 update the file in $(INSTANCE_HOME)/tmp.

Updating a (disk based) file and monkey patching don't seem to
go together in my mind.  I'm really unclear what you are proposing
here.

   2)  If the monkey patch is installed, then the installed file is
  written in $(INSTANCE_HOME)/tmp.  I.e., the new manage_main.py
  is written to $(INSTANCE_HOME)/tmp.

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?

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).

--RDM


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread Casey Duncan

I know I will regret that I said this, but this is really symptomatic of a 
more basic need. The need to extend manage_main.

This has been identified as a hot spot for products to monkey with. Why 
don't we go right to the source and make manage_main extensible so that 
monkey patching it isn't necessary?

-Casey

On Tuesday 13 August 2002 01:22 pm, Jim Penny wrote:
 There is a large problem looming with Moneky Patches.  The problem is
 that monkey patches are so Highlander.  There can be Only One.
 
 For example, there are at least five or six products that monkey patch
 manage_main.   Each simply replaces whatever manage_main exists at the
 time of instantation, and blows away any previous monkey patch.  Some
 coordinated way of dealing with this problem needs to be arrived at.
 
 Proposal:
 
   for concreteness sake, suppose manage_main is being patched.
 
   A monkey patch author does the following:
 
   1)  checks to see if the file being patched is in $(INSTANCE_HOME)/tmp
 
 A)  If not, he proceeds directly with the patch
 
 B)  If so, he makes whatever checks he can to determine if he can
 update the file in $(INSTANCE_HOME)/tmp.
 
   i)  If he cannot, it is his decision whether to follow current
   practice and simply blow away the current monkey patch 
   (Boo!  Hiss!)  or,
   
   ii)  fail (sigh, curse!).
 
   2)  If the monkey patch is installed, then the installed file is
  written in $(INSTANCE_HOME)/tmp.  I.e., the new manage_main.py
  is written to $(INSTANCE_HOME)/tmp.
 
   This assumes that z2.py is modified so that it clears out
   $(INSTANCE_HOME)/tmp on each start.
 
 It might be also be a good idea to keep a section of comments at the
 top of the monkeypatch file showing the history of monkeypatch
 application.
 
 Comments?
 
 Jim Penny
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread jlagarde

On Tue Aug 13, 2002, Jim Penny wrote:
 There is a large problem looming with Moneky Patches. The problem is
 that monkey patches are so Highlander. There can be Only One.
 
 For example, there are at least five or six products that monkey patch
 manage_main. Each simply replaces whatever manage_main exists at the
 time of instantation, and blows away any previous monkey patch. Some
 coordinated way of dealing with this problem needs to be arrived at.


And if you upgrade Zope, the patched version of manage_main will discard
any changes made in the new version of Zope.

 
 Proposal:
[ideas on how to check for previous changes and what to do about it]

Here is a more surgical option for small changes: Instead of
indiscriminately replacing the whole function or method, decompile and
look for and replace only that part of the code that you want to change.
In that way, as long as that part of the code remains valid between
versions, the change probably remains valid, and you apply it. If you
can't find the part of the code that you want to change, then some other
change you are not aware of happened, so do not apply your change. I use
decompyle and re to do the work. Here is an example:

-- code snippet from my site monkey patch product --
from decompyle import decompyle
import re
import cStringIO

# -
# 'Fix' dtml-in so previous-sequence and next-sequence are
# available everywhere in the batch
from DocumentTemplate.DT_In import InClass

tochangeF = cStringIO.StringIO()
decompyle(InClass.renderwb.im_func.func_code,out=tochangeF)
tochange = tochangeF.getvalue()
tochangeF.close()

# The change is to remove the if index == first | last conditions
print 'Changing dtml-in to provide previous and next sequence everywhere
in the batch'
tochange,num =
re.subn(rif\s+\(index\s*==\s*(first|last)\):\s*pkw\['(previous|next)-se
quence'\]\s*=\s*1,
  rpkw['\2-sequence'] = 1\n,tochange)
if num == 2:
print 'Success'
# Replacement seemed successful, so go ahead and make the swap
exec 'def renderwb(self,md):\n' + tochange.replace('\n','\n
')[:-4]
InClass.renderwb = renderwb
else:
print 'Was expected to make 2 changes, got %s. Check the DT_In code'
% num
-- end code snippet --

Of course, some monkey patches are so incompatible that even that
approach might not work or produce unexpected results.

Cheers,

Jean


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread Casey Duncan

On Tuesday 13 August 2002 02:10 pm, [EMAIL PROTECTED] wrote:
 On Tue Aug 13, 2002, Jim Penny wrote:
  There is a large problem looming with Moneky Patches. The problem is
  that monkey patches are so Highlander. There can be Only One.
  
  For example, there are at least five or six products that monkey patch
  manage_main. Each simply replaces whatever manage_main exists at the
  time of instantation, and blows away any previous monkey patch. Some
  coordinated way of dealing with this problem needs to be arrived at.
 
 
 And if you upgrade Zope, the patched version of manage_main will discard
 any changes made in the new version of Zope.

That is why it would be beneficial to make the thing being patched extensible 
in the first place thereby alleviating the need to patch it.

  Proposal:
 [ideas on how to check for previous changes and what to do about it]
 
 Here is a more surgical option for small changes: Instead of
 indiscriminately replacing the whole function or method, decompile and
 look for and replace only that part of the code that you want to change.
 In that way, as long as that part of the code remains valid between
 versions, the change probably remains valid, and you apply it. If you
 can't find the part of the code that you want to change, then some other
 change you are not aware of happened, so do not apply your change. I use
 decompyle and re to do the work. Here is an example:

[snip example]

I thought about an approach like this, but I think it is susceptible to subtle 
bugs. It is very hard to predict the interaction of products independently 
changing the same template. As a product author, trying to support such a 
thing is not very attractive.

I would prefer to make the template itself more flexible then try to jam new 
code into it sideways at run-time.

-Casey

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread R. David Murray

On Tue, 13 Aug 2002, Casey Duncan wrote:
 That is why it would be beneficial to make the thing being patched extensible
 in the first place thereby alleviating the need to patch it.

This is a very good point.  Now that we have comitters outside
zope corp, Product authors probably ought to think of this as
an opportunity to refactor the base zope code.  In other words,
if you need to monkey patch, instead refactor the code so that
there's a hook you can use, and submit the patch for inclusion in
the next version of zope.  Then you can monkey patch if you need
to make your product work with the current zope version, but you
won't have to worry about upgrade issues.

--RDM


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches

2002-08-13 Thread Jerome Alet

Hi,

On Tue, Aug 13, 2002 at 01:56:22PM -0400, Casey Duncan wrote:
 I know I will regret that I said this, but this is really symptomatic of a 
 more basic need. The need to extend manage_main.
 
 This has been identified as a hot spot for products to monkey with. Why 
 don't we go right to the source and make manage_main extensible so that 
 monkey patching it isn't necessary?

What about my proposal of June 6th 2002 in zope-dev ?

URL : 

http://zope.nipltd.com/public/lists/dev-archive.nsf/0a8715d5f3c7b6a3802568c1006328f7/978989b0fe9f889180256bd0004cf9c1?OpenDocumentHighlight=0,plugins

I had no answer.

bye,

Jerome Alet

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )