On Aug 18, 2009, at 07:11 PM, Curtis Hovey wrote: >This is very good. I know you had concerns about the menus, but I think they >are close to solving the issues in this branch and in the other top-level >collections. I think a subtle renaming of the marker interface will help you >see what I see. I have a code fragment at the bottom of how I would name and >restructure the menus so that you have something ready for your next branches. Yep, it's been a frustrating branch; thanks for talking me off the ledge. Thanks for the review and it's definitely encouraging to see how close this branch puts me to completing the other top level collections. >... >> === modified file 'lib/canonical/launchpad/icing/style-3-0.css' >> --- lib/canonical/launchpad/icing/style-3-0.css 2009-08-17 11:22:39 +0000 >> +++ lib/canonical/launchpad/icing/style-3-0.css 2009-08-17 17:50:02 +0000 >> @@ -590,3 +590,10 @@ >> word-wrap: break-word; >> } >> >> +/* ==== Listing tables ==== */ >> + >> +table.listing thead { >> + color: #9f2b33; > >This colour is the bug colour. We need something neutral #333; maybe. I never made the correlation between the heading color and the app color. I thought it was a general heading cue. If not, then I think the default color setting is just fine. You provided the hint for bolding the th in a comment on the bug and that works better, so I'll keep that and remove the color setting. >> + font-size: 1.125em; > >This font-size is not supported by YUI. We must specify all sizes >using the percentages from the table in this file. try 116% or 123.1%. 116% looks good to me. >> === modified file 'lib/canonical/launchpad/webapp/batching.py' >> --- lib/canonical/launchpad/webapp/batching.py 2009-06-25 05:30:52 +0000 >> +++ lib/canonical/launchpad/webapp/batching.py 2009-08-14 18:41:41 +0000 >> @@ -62,6 +62,10 @@ >> def max_batch_size(self): >> return config.launchpad.max_batch_size >> >> + @property >> + def multiple_pages(self): > >can you add a docstring? Is has_multiple_pages a better name for what it >returns? Docstring added. 'multiple_pages' was the original name for the property before refactoring, but I agree that 'has_multiple_pages' is a better name. So changed. >> === modified file 'lib/lp/code/browser/branchlisting.py' >> --- lib/lp/code/browser/branchlisting.py 2009-08-13 04:08:38 +0000 >> +++ lib/lp/code/browser/branchlisting.py 2009-08-18 14:11:56 +0000 >> @@ -331,56 +331,13 @@ >> branches = list(self.currentBatch()) >> # XXX: TimPenhey 2009-04-08 bug=324546 >> # Until there is an API to do this nicely, shove the launchpad.view >> - # permission into the request cache directly. This is done because the >> - # security proxy sometimes causes extra requests to be made. >> + # permission into the request cache directly. This is done because >> + # the security proxy sometimes causes extra requests to be made. >> request = self.view.request >> precache_permission_for_objects(request, 'launchpad.View', branches) >> return branches >> >> @cachedproperty >> - def branch_ids_with_bug_links(self): > >I am not sure why this big chunk of code was removed. I this diff lying? It's not! I mentioned this in my cover letter. 'make lint' complained about duplicate methods in this class and in fact the methods I removed were being shadowed by methods later in the same class, with the same name. There's no way these methods could have been called (that I can think of anyway!) by any other code. I think they are just dead code left after a refactoring, so I removed it. I ran ec2 on revno 9127 of the branch and it passed, so if it doesn't break a test, it wasn't needed . >> === added file 'lib/lp/registry/browser/menu.py' >> --- lib/lp/registry/browser/menu.py 1970-01-01 00:00:00 +0000 >> +++ lib/lp/registry/browser/menu.py 2009-08-18 13:54:51 +0000 >> @@ -0,0 +1,40 @@ >> +# Copyright 2009 Canonical Ltd. This software is licensed under the >> +# GNU Affero General Public License version 3 (see the file LICENSE). >> + >> +"""Shared menus.""" >> + >> +__metaclass__ = type >> +__all__ = [ >> + 'TopLevelMenuMixin', >> + ] >> + >> + >> +from canonical.launchpad.webapp.menu import Link >> + >> + >> +class TopLevelMenuMixin: >> + """Menu shared by top level collection objects.""" > >I think I would prefer this in __init__.py where other shared code >is? Since these collections are in the root of the mainsite, I would >look in __init__.py for them Personally, I really don't like putting much if any code in __init__.py. In a sense, that code is hidden (though not as bad as filling __init__.py with lots of from-import-*'s). Other people may really like putting code in __init__.py, but my sensibilities here are shaped by early discussions about it when Python packages were being designed. At the time, Guido even debated whether it should be legal to put anything in an __init__.py at all! While it makes sense to allow it (and to put those names in the package's namespace), I think this is way overused in Launchpad. Others might disagree. > >What other menus would go in this module to justify it? I'm not sure anything else /has/ to go into this module to justify it. I personally like keeping modules short and sweet. >... > >> + def meetings(self): >> + return Link('/sprints/', 'View meetings', icon='info') > >Seeing this really make me think we need to separate sprints from >blueprints. I am certain this link belongs to the mainsite (which >is registry) mainsite seems reasonable. Is there something you want me to change here? >> + def create_account(self): >> + text = 'Create an account' >> + return Link('/people/+login', text, icon='add') > >^ This state will not always be right. Use the enabled kwarg like >we do other user variable links. > > def create_account(self): > text = 'Create an account' > enabled = self.context.user is None: > return Link('/people/+login', text, icon='add', enabled=enabled) Right. As you saw down below I enabled this link in a different way. Yours is better so I've made the change. I also took the opportunity to s/products/projects/ in TopLevelMenuMixin. I'm just waiting for a swine+bird flu (club sandwich pandemic?) to lay me up in bed for a week so I can do a mass mechanical change of product->project and project->project group. >> === modified file 'lib/lp/registry/browser/person.py' >> --- lib/lp/registry/browser/person.py 2009-08-03 15:21:35 +0000 >> +++ lib/lp/registry/browser/person.py 2009-08-18 15:28:28 +0000 > >... > >> @@ -1348,35 +1335,64 @@ >> return self.proposed_memberships or self.invited_memberships >> >> >> -class FOAFSearchView: >> +class IPeopleSearchNavigationMenu(Interface): >> + """Marker interface for people search navigation menu.""" > >I bet you will have to rename this in the next branch. Looking at the links >below, this is the IRegistryCollectionNavigationMenu and you want all the >collection search views to > > implements(IRegistryCollectionNavigationMenu) > >So you have one marker interface, and one implementation below that >is used in 5 collections. Your other branches will be much smaller. >I think this is what you intend to do placed the like definitions in >a shared place. Well, now I have my justification for menu.py! :) > >> +class PeopleSearchNavigationMenu(NavigationMenu, TopLevelMenuMixin): >> + """Navigation menu for people search.""" > >Most of the links are not for people search, they are for top-level >registry collections. Agreed! Changes made. > >> + usedfor = IPeopleSearchNavigationMenu >> + facet = 'overview' >> + >> + links = ['products', 'distributions', 'people', 'meetings', >> + 'register_team', 'register_project'] > >I think we should show projectgroups too. Agreed! Added. > >> + def initialize(self): >> + """See `MenuBase`.""" >> + if self.context.user is None: >> + # Make a copy of the links so as not to permanently mutate the >> + # class attribute. >> + self.links = PeopleSearchNavigationMenu.links[:] >> + self.links.append('create_account') > >^ This is contrary to how we do this in other menus. We use the links >enabled attribute to control that and we enabled or disable it based >on state. I think you can remove this method. > >Other than register a project, I think the collections are a related >paged menu. Actually, where are merging links: > > Admin merge people > Admin merge teams > Merge accounts After discussion on IRC between you, Martin, and myself, we decided to remove the inline text for the two admin functions and move them into the menu. I've left the person-merge-request link inline though since this is something that normal people will use. I also took the opportunity to disable the 'register' menu links for anonymous users. >You can define a menu for the context object like this: > >{{{ >class PersonSetNavigationMenu(NavigationMenu, TopLevelMenuMixin): > """Navigation menu for people search.""" > > usedfor = IPerson > facet = 'overview' > > links = [register_team', 'register_project', ... ] >}}} > >And it will be available to every PersonSet page. Then use the action menu >like > > > >The related pages menu would be > > I see you have a more fleshed out example below... > >> +class PeopleSearchView(LaunchpadView): >> + """Search for people and teams on the /people page.""" >> + >> + implements(IPeopleSearchNavigationMenu) > >If we plan for a single collection menu used by all then this line >would be: > > implements(IRegistryCollectionNavigationMenu) > >... > >> === modified file 'lib/lp/registry/browser/product.py' >> --- lib/lp/registry/browser/product.py 2009-08-12 13:20:10 +0000 >> +++ lib/lp/registry/browser/product.py 2009-08-18 13:54:51 +0000 >... >> @@ -546,40 +547,17 @@ >> enable_only = ['overview'] >> >> >> -class ProductSetContextMenu(ContextMenu): >> +class ProductSetContextMenu(ContextMenu, TopLevelMenuMixin): >> >> usedfor = IProductSet >> >> links = ['products', 'distributions', 'people', 'meetings', >> - 'all', 'register', 'register_team', 'review_licenses'] > >I am no sure we need this any more. ContextMenus are 1.0. We are using >Just change ContextMenu to NavigationMenu and the conversion is done I think. > >Oh, except that the links to the other collections belong in >IRegistryCollectionNavigationMenu. This is just a refactoring, so I'd rather leave this as a task for the next branch. On the plus side, with all the changes here it should go very quickly! >> === added file 'lib/lp/registry/browser/tests/people-views.txt' >> --- lib/lp/registry/browser/tests/people-views.txt 1970-01-01 00:00:00 +0000 >> +++ lib/lp/registry/browser/tests/people-views.txt 2009-08-14 17:31:10 +0000 >> @@ -0,0 +1,70 @@ >> +============================== >> +Searching for people and teams >> +============================== >> + >> +The view behind the /people page provides searching for people and teams. The >> +view knows how many people and teams are currently registered in Launchpad. >> + >> + >>> from lp.registry.interfaces.person import IPersonSet >> + >>> login('