[Framework-Team] Menus

[Martin Aspeli]

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')
   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?

Martin

-- 
(muted)