launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

On Wed, 18 Aug 2010 11:49:01 -0400, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
> 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 think I'm lacking some context here, like what a menu is in the
Launchpad context.  Let me guess a little: a Menu is a collection of
Links.  There is one menu per instance of a LaunchpadView subclass.
Links can be disabled or enabled.

The Menu itself can be rendered, and renders each link one after the
other, but we don't ever do this these days.

>       * 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.

So when the Menu is constructed, all Links in the menu are checked to
see if they're enabled, even if they are never rendered?  That seems
like a pretty clear bug.

>       * 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

Because the menu instance is associated with the view instance,
rendering a portlet, even if it's a view on the same view class, will
create the menu over again?

>       * 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.

Doesn't the link just use morally the same code as fmt:link?  If not, it
should?  If it does, this bug should be fixed there?

facet is an obsolete idea of course. s/facet/layer/g.

> 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.

Yeah, that's stupid.

>       * The menus assume that they are instantiated once per request
>         because of the previous point.

This can never have been really true.

>       * 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.

Links are certainly convenient.

> Guidelines for expected behaviour
> 
>       * We build menus once per request. Getting an object's menu is
>         free once it is instantiated.

So this means menus are associated with context objects, not with view
instances?  (Maybe this is already true).

>       * 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.

Right.  In fact, getting the object's menu should be trivial -- it's
only getting a link out of that menu that should be non-trivial, and we
should cache the link in the request once its accessed.

>       * Links are setup when they are accessed. There is no cost for a
>         link that is not used.

I think this is what I just said :-)

> 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.

OK, I think this means some of my guesses above are wrong.  I hope this
mail still has value :-)

What on earth is a facet menu?

Cheers,
mwh