[Framework-Team] Re: Menus

Hanno Schlichting plone at hannosch.info
Sun Apr 9 22:39:15 UTC 2006


Martin Aspeli wrote:
> Hi guys,
> 
> The viewlet craze started because I wanted to investigate pluggable UIs,
> but was actually mostly driven by the fact that I hate the monolithic
> ugliness that is global_contentmenu.pt. Now, a viewlet is basically just
> a free-form HTML snippet (the examples all return them as strings in
> Python, ouch). A viewlet sits in a viewlet manager, which another
> html-producing thing that knows how to aggregate viewlets (do you put
> each inside a div or a span, basically).
> 
> The contentmenu wouldn't benefit from any such thing. We want to have
> menus, with common markup. We don't want people to shove an h1 in there.
> :) However, menus are by definition context dependent, and are (via
> actions for the content tabs) in the rest of Plone.
> 
> I'd like to PLIP before the Archipelago sprint something like this:
> 
>  - global_contentmenu.pt uses a view @@content_menu that builds all that
> nastiness and does all the conditionals.
> 
>  - the main part of that will be something that just loops over a tuple
> of IContentMenu objects that list IContentMenuItem objects:
> 
> 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 :)

>   children = Attribute('An ordered list of children of this menu, all
> should be IContentMenuItem')
>   fallbackUrl Attribute('The url to use if JavaScript is disabled')
> 
> class IContentMenuItem(Interface):
>   id = Attribute('The id of the menu item')
>   title = Attribute('The title displayed')
>   icon = Attribute('The path to an icon to render')
>   url = Attribute('The URL to link to')
> 
> okay, you get the idea - lightweight objects that are assembled in the
> view and thus can be displayed generically: loop over the menus, and for
> each, loop over the menu items.
> 
>  - The view builds these menus by adapting the context to an
> IContentMenuProvider that returns an appropriately ordered set of
> IContentMenu items (using their 'before' attribute, which lets a menu
> say "I want to be before the display menu", for example). The default
> implementation of this should look up all utilities implementing
> IContentMenuProvider (or some secondary interface if that makes more
> sense) and aggregate the menus they contain. The idea is that you can
> register a site-global menu (or one that conditionally is displayed) by
> registering a (local) utility, whilst you can totally override all the
> menus by providing a different adapter (or you could do both - provide a
> new adapter that calls the base class behaviour and adds some of its own
> menus).
> 
> 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.

Hanno




More information about the Framework-Team mailing list