[Framework-Team] Re: Menus

Martin Aspeli optilude at gmx.net
Sun Apr 9 22:53:53 UTC 2006

On Sun, 09 Apr 2006 23:39:15 +0100, Hanno Schlichting  
<plone at hannosch.info> wrote:

>> class IContentMenu(Interface):
>>   id = Attribute('The id of the menu')
>>   before = Attribute('The id this menu should be rendered before, or  
>> None')
>>   title = Attribute('The title displayed')
>>   i18n_key = Attribute('The i18n key of the menu')
> Ah no! No more insane keys for i18n! Forget the Archetypes crap! Read
> about Messages ;) In this case the title wouldn't be a simple Unicode
> string but a Message. If you define menus in ZCML they are automatically
> turned into Messages :)

Thanks. :) This was only a thinking-out-loud post, I didn't actually mean  
that to be the final implementation.

I don't think ZCML is the way to go here, though, since that's Zope-global  
and we need things that can be constructed dynamically (not sure if that's  
what you meant anyway).

>> Does this sound like a sensible idea?
> It does. As far as I understand this menus are the replacement for
> actions, so this sounds like something where we might want to have a
> generic base solution in CMF and not in Plone. But I guess it would be
> possible to experiment with this on a special Plone case and once we get
> the feeling of understanding all the odds and ends push something back
> to the CMF level.

Possible. I'm a bit dubious to the idea of generic actions being used  
everywhere. Actions are very useful for things like the content tabs,  
because they're effectively global (either on the portal-type level or on  
the portal-wide level), one-level and easily grouped with a small number  
of magic strings (the categories like object_tabs or folder_tabs). I'm not  
convinced that model scales up, though, neither in UI (how do you  
represent hierarchical menus in this way?), in performance (the actions  
code is fairly slow because it has to evaluate a lot of TALES expressions)  
or to our needs: it's very hard (impossible?) to dynamically create  
actions on the fly (e.g. only display menu item Foo if user has set  
property X in some configlet).

It's true that the menu items are actions (link + icon + title), but that  
concept is very generic and if all we want is to re-use that data  
structure, then the case for re-use is fairly narrow. The advantage (?) of  
doing it separately is that the interfaces and implementation carry  
semantic meaning - it's a specific task to register a content menu.  
Perhaps we'd have other drop-down menus that would work in the same way,  
though then you still need magic 'category' strings or similar to  
distinguish what goes where. Interfaces can be type checked, strings  
can't. :)



More information about the Framework-Team mailing list