[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. :)
Martin
--
(muted)
More information about the Framework-Team
mailing list