Merge lp:~wallyworld/launchpad/recipe-find-related-branches into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Ian Booth on 2010-12-19 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 12111 |
| Proposed branch: | lp:~wallyworld/launchpad/recipe-find-related-branches |
| Merge into: | lp:launchpad |
| Diff against target: |
610 lines (+458/-4) 4 files modified
lib/lp/code/browser/sourcepackagerecipe.py (+107/-2) lib/lp/code/browser/tests/test_sourcepackagerecipe.py (+282/-2) lib/lp/code/templates/sourcepackagerecipe-new.pt (+3/-0) lib/lp/code/templates/sourcepackagerecipe-related-branches.pt (+66/-0) |
| To merge this branch: | bzr merge lp:~wallyworld/launchpad/recipe-find-related-branches |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Tim Penhey (community) | 2010-12-03 | Approve on 2010-12-19 | |
| Steve Kowalik (community) | code* | 2010-11-29 | Approve on 2010-12-03 |
|
Review via email:
|
|||
Commit Message
[r=stevenk,
Description of the Change
= Summary =
Bug 670452 - add a facility to SourcePackageRecipe add/edit pages to show branches related to the base branch of the recipe being added/edited.
= Implementation =
A custom widget was created: RelatedBranches
What is rendered is a collapsible section called "Related Branches". This has 2 branches listings - related package branches and related series branches.
= Screenshot =
http://
= Tests =
bin/test -vvt test_sourcepack
New tests were added:
test_
test_
test_
test_
test_
test_
test_
test_
The tests checked that if there were no related branches, the new widget was no rendered, and also checked the contents of the page when related branches were present.
A small drive by improvement was made to the test_create_
= Lint =
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
511: E501 line too long (80 characters)
1023: E501 line too long (85 characters)
1037: E501 line too long (89 characters)
1049: E501 line too long (85 characters)
1064: E501 line too long (89 characters)
1080: E501 line too long (85 characters)
511: Line exceeds 78 characters.
1023: Line exceeds 78 characters.
1037: Line exceeds 78 characters.
1049: Line exceeds 78 characters.
1064: Line exceeds 78 characters.
1067: Line exceeds 78 characters.
1080: Line exceeds 78 characters.
./lib/lp/
1: unbound prefix
| Ian Booth (wallyworld) wrote : | # |
lint errors (almost all line length) were there already and since this
code base is relatively new, I figured I'd leave well enough alone.
I'll see if I can tweak the zcml instead of using removeSecurityProxy
Thanks.
On 03/12/10 15:01, Steve Kowalik wrote:
> Review: Approve code*
> This looks great! My only concerns are the lint errors, and the (it seems to me) excessive use of removeSecurityP
| Ian Booth (wallyworld) wrote : | # |
I had a look at the 3 usages of removeSecurityProxy in the new code:
The ones in createRelatedBr
naked_product is required for ICanHasLinkedBr
sourcepackage is required for ICanHasLinkedBr
In checkRelatedBra
naked_branch is not required so has been removed
On 03/12/10 15:07, Ian Booth wrote:
> lint errors (almost all line length) were there already and since this
> code base is relatively new, I figured I'd leave well enough alone.
>
> I'll see if I can tweak the zcml instead of using removeSecurityProxy
>
> Thanks.
>
> On 03/12/10 15:01, Steve Kowalik wrote:
>> Review: Approve code*
>> This looks great! My only concerns are the lint errors, and the (it seems to me) excessive use of removeSecurityP
| Tim Penhey (thumper) wrote : | # |
I have two issues with this branch.
1) What do we show when we can't find any related branches?
2) Creating a widget is overkill for what is needed, which is some text on the page.
| Ian Booth (wallyworld) wrote : | # |
On 06/12/10 14:22, Tim Penhey wrote:
> Review: Needs Fixing
> I have two issues with this branch.
>
> 1) What do we show when we can't find any related branches?
>
Nothing. The page appears as it does now before the branch. Do you want
some text to say something like "No related branches"? I didn't think
that was needed but can easily add it.
> 2) Creating a widget is overkill for what is needed, which is some text on the page.
The page template uses this construct to render the form:
<div metal:use-
The first implementation this branch involved replacing the above with a
macro:
<div metal:use-
which:
- expanded the default metal form definition to explicitly list the
required form fields to display:
- adds the related branches markup after all the form fields are specified
eg
<div metal:use-
<tal:product-name define="widget nocall:
<metal:block use-macro=
</tal:
<tal:product-name define="widget nocall:
<metal:block use-macro=
</tal:
<another form field...>
<another form field...>
<!-- markup for related branches goes here -->
<table>
xxxx
</table>
</div>
The macro was used for the add and edit page templates. Because the edit
form used the generic edit template, a new sourcepackagere
template was created.
I thought that expanding the default form element and explicitly listing
the form fields in the page template was perhaps not the best approach
since a change to the form schema would require editing several
different files. The current implementation programatically adds the
custom field used to display the related branches to the form schema and
is more robust to changes in the underlying form.
I can revert to this approach is that's considered better.
| Tim Penhey (thumper) wrote : | # |
On Tue, 07 Dec 2010 03:11:15 you wrote:
> On 06/12/10 14:22, Tim Penhey wrote:
> > Review: Needs Fixing
> > I have two issues with this branch.
> >
> > 1) What do we show when we can't find any related branches?
>
> Nothing. The page appears as it does now before the branch. Do you want
> some text to say something like "No related branches"? I didn't think
> that was needed but can easily add it.
No, I think that nothing is better. I take it that the fieldset isn't rendered
at all when there are no branches?
> > 2) Creating a widget is overkill for what is needed, which is some text
> > on the page.
>
> The page template uses this construct to render the form:
>
> <div metal:use-
>
> The first implementation this branch involved replacing the above with a
> macro:
>
> <div metal:use-
There is a simpler way, which I happen to have done with my "ppa creation
during new recipe" branch, which does expand all the rendered widgets.
The form macro defines a number of slots which can be replaced. However with
my new change (which I know you didn't know about), it is easier to just add a
simple rendering, and have the methods to get the branches on the Add view
class. Perhaps you might want to merge my branch and make yours dependent on
it?
This is one of the problems of having multiple people hacking on the same
area.
| Ian Booth (wallyworld) wrote : | # |
>>>
>>> 1) What do we show when we can't find any related branches?
>>
>> Nothing. The page appears as it does now before the branch. Do you want
>> some text to say something like "No related branches"? I didn't think
>> that was needed but can easily add it.
>
> No, I think that nothing is better. I take it that the fieldset isn't rendered
> at all when there are no branches?
>
Correct. There's a tal condition wrapping the fieldset.
>
> There is a simpler way, which I happen to have done with my "ppa creation
> during new recipe" branch, which does expand all the rendered widgets.
>
> The form macro defines a number of slots which can be replaced. However with
> my new change (which I know you didn't know about), it is easier to just add a
> simple rendering, and have the methods to get the branches on the Add view
> class. Perhaps you might want to merge my branch and make yours dependent on
> it?
>
> This is one of the problems of having multiple people hacking on the same
> area.
Thanks for the info. I'll use the new code to improve my implementation.
| Ian Booth (wallyworld) wrote : | # |
>
>>> 2) Creating a widget is overkill for what is needed, which is some text
>>> on the page.
>>
>> The page template uses this construct to render the form:
>>
>> <div metal:use-
>>
>> The first implementation this branch involved replacing the above with a
>> macro:
>>
>> <div metal:use-
>
> There is a simpler way, which I happen to have done with my "ppa creation
> during new recipe" branch, which does expand all the rendered widgets.
The custom widget is the way to do it with least code changes. It's not
just a simple field rendering as is the case with the ppa stuff -
there's an entire page template file which renders the tables and links
etc. Using another method eg a macro involves editing zcml and adding an
extra page template for the edit form etc. So I'd like to land it as is
if possible.
| Tim Penhey (thumper) wrote : | # |
Can you move the functionality in the render method into the setupWidgets?
Apart from that, you are good to go.
| Ian Booth (wallyworld) wrote : | # |
> Can you move the functionality in the render method into the setupWidgets?
>
> Apart from that, you are good to go.
Done

This looks great! My only concerns are the lint errors, and the (it seems to me) excessive use of removeSecurityP roxy.