launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

I have seen menus show up in oopses, I have seen engineers on IRC
surprised to see a query cause by a menu, but I have not seen an outline
of the menu problem. I think I can summarise the problem and provide
some guidelines about how we want menus to behave.

      * I recently saw Martin Pitt could not see his +participation page
        because of a timeout reached querying all his uploads. This is
        because a link in the person overview menu is only enabled if
        the person has uploads. The page does *not* use this link.
      * Many templates define an instance of a menu at the start of the
        markup to avoid the cost of duplicate instances, but we know
        that the menu will be reinstantiated in a portlet. Creating
        reusable markup often means death by menu queries
      * Even though a link is defined in the overview menu (mainsite),
        and a link's view defines its facet, the menu makes the link URL
        to the current host eg. we had a 404 on code.lp.net for
        +downloads and we could not use the menu to get the correct
        link.

I think the root problem is that our menu implementation is 5 years old.
I received a minor update 2 years ago, but they are not engineered to be
used as we use them. 

      * The menus assume links are used one on a page and that the menu
        is used to render a list. Only the NavigationMenu does this now.
        All menus iterate over all link names in a list setup all links.
      * The menus assume that they are instantiated once per request
        because of the previous point.
      * Most uses for a menu are like a dictionary/bag where we get the
        links as needed. This often means we are doing multiple
        instantiations.
      * Users demand that we not show links if there is no information
        on the destination page, so we are doing more writing more
        "enabled" rules.
      * We want to use menus to get list instead of crafting links in
        the template because we want to define a link once, and test it
        once.

Guidelines for expected behaviour

      * We build menus once per request. Getting an object's menu is
        free once it is instantiated.
      * We know that at the point we start rendering, that no link can
        change--once a link object is setup, we must never do it again.
      * Links are setup when they are accessed. There is no cost for a
        link that is not used.

I think we also need to ask if we really need both context menu and a
facet menu. The facet menu implies we can have separate application
concerns, but in practice, I think pages/templates cannot do that to
provide good user experience. The context menu implies there is one
massive definition of all an object's links, but they are rarely all
used. I removed a lot of links from context menus after I added a test
of the links and discovered that there is not ZCML definition of the
view any more.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part