Merge lp:~wallyworld/launchpad/branch-infotype-portlet2-1040999 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Ian Booth on 2012-08-29 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 15875 |
| Proposed branch: | lp:~wallyworld/launchpad/branch-infotype-portlet2-1040999 |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~wallyworld/launchpad/branch-infotype-portlet-1040999 |
| Diff against target: |
730 lines (+516/-72) 9 files modified
lib/lp/app/javascript/information_type.js (+83/-0) lib/lp/bugs/javascript/information_type_choice.js (+17/-69) lib/lp/bugs/javascript/tests/test_information_type_choice.html (+2/-0) lib/lp/bugs/javascript/tests/test_information_type_choice.js (+2/-2) lib/lp/code/browser/branch.py (+1/-1) lib/lp/code/javascript/branch.information_type_choice.js (+122/-0) lib/lp/code/javascript/tests/test_information_type_choice.html (+96/-0) lib/lp/code/javascript/tests/test_information_type_choice.js (+179/-0) lib/lp/code/templates/branch-portlet-privacy.pt (+14/-0) |
| To merge this branch: | bzr merge lp:~wallyworld/launchpad/branch-infotype-portlet2-1040999 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Richard Harding (community) | 2012-08-28 | Approve on 2012-08-28 | |
|
Review via email:
|
|||
Commit Message
Add javascript widget to edit branch information type, refactor out common code.
Description of the Change
== Implementation ==
This branch adds the javascript code to provide a popup choice widget for editing branch information type.
There is already similar functionality for editing bug info type, so common code was pulled out and put in a common module which both import and use.
== Tests ==
Add new yui tests for branch info type widget, update existing yui tests for bug info type widget.
== Lint ==
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
| Richard Harding (rharding) wrote : | # |
| Ian Booth (wallyworld) wrote : | # |
> Just a quick comment in looking over things. It would be best if the banner,
> portlet, and the actual change widget all communicated via an event vs direct
> calls. The widget should just fire a 'privacy_
> banner and portlet can listen to and respond as required. In this way you're
> not tied to having these exact parts in place and code couple possibly be
> shared more from bug/code uses. Any data needed can be passed into the event
> as misc data.
Yes, agree. The common functionality is factored out into a separate module in this branch. The decoupling using events can happen later though since this branch is large enough already and is simply building on what was there previously.
| Richard Harding (rharding) wrote : | # |
#30
Are there better names we can use than key, key_name? I'm not sure how they're supposed to be different. I see later that you're giving it a key in the cache to find the data. How about cache_key and then type_name, type_value?
#307
You don't need to call the superclass for renderUI. It's meant to be implemented by your class.
http://
#333
Same for bindUI
http://
#335
Can you just move the check for the privacy_link node into the initializer() of the class and set an attribute that's a kill switch. Then all the code should just check its own ATTR
if this.get('enabled')
or something. One method is checking for a node to determine if it should run, the next method then starts checking things the previous one creates and it's a bit of a stack of cards.
| Ian Booth (wallyworld) wrote : | # |
Thanks Rick.
> #30
> Are there better names we can use than key, key_name? I'm not sure how they're
> supposed to be different. I see later that you're giving it a key in the cache
> to find the data. How about cache_key and then type_name, type_value?
>
The names made sense to me :-)
I'll look at renaming.
>
> #335
> Can you just move the check for the privacy_link node into the initializer()
> of the class and set an attribute that's a kill switch. Then all the code
> should just check its own ATTR
>
> if this.get('enabled')
>
> or something. One method is checking for a node to determine if it should run,
> the next method then starts checking things the previous one creates and it's
> a bit of a stack of cards.
Sure. Will do that.

Just a quick comment in looking over things. It would be best if the banner, portlet, and the actual change widget all communicated via an event vs direct calls. The widget should just fire a 'privacy_ value_change' event that the banner and portlet can listen to and respond as required. In this way you're not tied to having these exact parts in place and code couple possibly be shared more from bug/code uses. Any data needed can be passed into the event as misc data.