Merge lp:~bac/launchpad/bug-652280-pg-trans into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Brad Crittenden | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 11740 | ||||
Proposed branch: | lp:~bac/launchpad/bug-652280-pg-trans | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
320 lines (+191/-14) 7 files modified
lib/lp/registry/doc/projectgroup.txt (+11/-0) lib/lp/registry/model/projectgroup.py (+8/-2) lib/lp/testing/views.py (+4/-2) lib/lp/translations/browser/project.py (+1/-0) lib/lp/translations/browser/tests/test_noindex.py (+152/-0) lib/lp/translations/templates/distroseries-translations.pt (+2/-5) lib/lp/translations/templates/project-translations.pt (+13/-5) |
||||
To merge this branch: | bzr merge lp:~bac/launchpad/bug-652280-pg-trans | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Approve | ||
Jeroen T. Vermeulen (community) | code | Approve | |
Curtis Hovey | code | Pending | |
Review via email: mp+38195@code.launchpad.net |
Description of the change
= Summary =
The +translations page for project groups did not have the
"noindex,nofollow" meta data. It was added as was a new test that tests
all translations pages to ensure the meta data is included properly.
== Proposed fix ==
As above.
== Pre-implementation notes ==
Talks with Curtis and detailed work with Henning.
== Implementation details ==
It's pretty straightforward, as above. However, for distroseries
getting a view via 'create_
does not work, due, I think, to the way the pages are registered in the
ZCML with respect to layers and facets. The template uses the
navigation menus which are not adapted properly.
In the end I punted and used getUserBrowser in order to get the rendered
content of the pages which is a fine approach but leaves the mystery of
why getting the view directly and rendering it does not work. Is there
a hidden bug that I've discovered but didn't crack?
== Tests ==
bin/test -vvm lp.translations -t test_noindex
== Demo and Q/A ==
Go to +translations and inspect the HTML for the anti-robots meta
instructions.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Hi Brad,
Nice to see a branch with a solid cover letter again.
You found some interesting bugs in Storm's SQLObject compatibility layer while working on this: is_empty returns the inverse of what it should, and then __nonzero__ compounds that sin by inverting it again. I hope you'll file a bug about this.
I have no objections to the code overall. There are a few things in the test that I'd like to see fixed, but nothing to stop an approval:
* You use lower_case_ with_underscore s for their helper methods, whereas our coding standard mandates sayItWithCapitals for methods (but methods only). The requirement may be going away though; I haven't kept track.
* You pointed out that there's a redundant get_rendered_ contents in the products test. To be removed.
* You also pointed out that there's already a has_translatables on your context object, so no need to duplicate it in the view.
* Why do you bother making "target" and "naked_ translatable" properties instead of attributes that you initialize in setUp? I do appreciate the docstring but a comment would be fine as far as I'm concerned. You could scratch self.product, self.projectgroup, self.distro, and self.distroseries to make up for it; they would become unnecessary.
* I like the orthogonal test setup, with a mixin for the test scenarios and leaf classes for the different alternate setups. But I find the inheritance graph a little confusing. I think it'd be more manageable if the actual test cases were all leaf classes, without test cases inheriting from other classes that will also run as separate test cases. I'd also put the layer specifications in those leaf classes, so that there's a clear separation between the classes that "go into" a test case and the individual test cases.
* You have your own verification methods (verify_ robots_ are_blocked, verify_ robots_ are_not_ blocked) that invoke other assertion methods. I normally avoid this myself because it hides the "where did it go wrong" information deeper in the traceback, but looking at this I quite like the way the naming documents the intent of the assertion.
* Isn't testing for exactly "noindex,nofollow" more brittle than needed? Would "nofollow,noindex" be equally valid? If so, it'd be more robust to assertContentEqual on robots[ 'content' ].split( ','). I'll admit it's far-fetched, but brittle tests have given us enough headaches to make us worry about these things.
* Out of interest, why do you pass rootsite to create_ initialized_ view for distroseries but not for productseries?
Jeroen