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 :        

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

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

Reply via email to