Merge lp:~michael.nelson/launchpad/644328-blacklist-ui into lp:launchpad/db-devel
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Michael Nelson on 2010-09-28 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 9843 | ||||
| Proposed branch: | lp:~michael.nelson/launchpad/644328-blacklist-ui | ||||
| Merge into: | lp:launchpad/db-devel | ||||
| Diff against target: |
774 lines (+414/-67) 15 files modified
lib/canonical/launchpad/icing/style-3-0.css.in (+1/-1) lib/canonical/launchpad/webapp/interfaces.py (+4/-0) lib/canonical/launchpad/webapp/servers.py (+23/-19) lib/canonical/launchpad/webapp/tests/test_servers.py (+14/-0) lib/lp/registry/browser/distroseriesdifference.py (+50/-4) lib/lp/registry/browser/tests/test_distroseriesdifference_views.py (+79/-3) lib/lp/registry/browser/tests/test_distroseriesdifference_webservice.py (+25/-0) lib/lp/registry/browser/tests/test_series_views.py (+0/-9) lib/lp/registry/interfaces/distroseriesdifference.py (+11/-0) lib/lp/registry/javascript/distroseriesdifferences_details.js (+122/-28) lib/lp/registry/model/distroseriesdifference.py (+5/-0) lib/lp/registry/templates/distroseries-localdifferences.pt (+4/-2) lib/lp/registry/templates/distroseriesdifference-listing-extra.pt (+12/-0) lib/lp/registry/tests/test_distroseriesdifference.py (+33/-0) lib/lp/registry/windmill/tests/test_distroseriesdifference_expander.py (+31/-1) |
||||
| To merge this branch: | bzr merge lp:~michael.nelson/launchpad/644328-blacklist-ui | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Henning Eggers (community) | code | Approve on 2010-09-27 | |
| Curtis Hovey (community) | ui | 2010-09-23 | Approve on 2010-09-27 |
| Guilherme Salgado (community) | ui* | 2010-09-23 | Approve on 2010-09-27 |
|
Review via email:
|
|||
Commit Message
Adds UI for blacklisting distroseriesdif
Description of the Change
Overview
========
This branch implements the UI for blacklisting source package differences for derived distro series.
See the LEP here:
https:/
and the specific mockup here:
https:/
You can view a 1min demo of the UI here:
http://
updated after salgado's ui review to:
http://
(Note: the issue I mention about the default radio not being selected in chromium was resolved by wrapping the inputs in an empty form element).
To test
=======
bin/test -vv -m test_servers -m test_distroseri
To demo locally:
================
Run http://
https:/
| Michael Nelson (michael.nelson) wrote : | # |
| Guilherme Salgado (salgado) wrote : | # |
<salgado> noodles775, I like the graying out because it makes it easy to see everything that was changed at a glance and maybe undo, but the text (as well as the links) is a bit too verbose (IMHO) and don't allow switching between all different states, so I was thinking of using 3 radio buttons there. "Blacklisted: (*) No, ( ) This version, ( ) All versions"
<salgado> but that's more like a nice-to-have thing, not that important
<noodles775> salgado: that actually sounds a bit like what I'd proposed on the mockup (a single 'Add to blacklist' that would then give you those options), but henninge convinced me on a previous MP that it was a bit too much... hangon, I'll find the discussion.
<salgado> well, except that the radio buttons allow you to see all the possible states without having to click anything
<salgado> just like the links do
<salgado> but sure, maybe he'll be able to convince me as well. :)
<noodles775> salgado: ok - if you search for blacklist at https:/
<noodles775> salgado: but I think your radio button option you mention could work too... Also, if you've got suggestions for making the text less verbose while still being easy to understand, let me know :)
<noodles775> s/you/that you/
<salgado> what I like about the radio button is that you see all the options without having to click anything and there's no repetition
<salgado> the downside is that you need vertical real estate, but you seem to have plenty of that
<salgado> as for the text of the link, the only thing I can think of is something like "Blacklist: _this version_ or _all versions_"
<salgado> but I don't quite like that as it seems to suggest you need to blacklist something
<noodles775> salgado: Yeah. RE the radio buttons, I was going to say that it would require two clicks (ie select/submit), but it doesn't of course... we could do the api update when an option is selected quite easily. And that would mean no need for 'Undo'. I like it more and more :)
<salgado> indeed, I hadn't thought about the undo
| Curtis Hovey (sinzui) wrote : | # |
I radio button the suggestion since it provides context. If I blacklist all version, I can still see an option to black list one version (and know I have made a mistake). This assumes there are three buttons and each fires an ajax event on change.
I think we have a "Undo" problem in Lp. It needs a standard presentation, an icon and rules about where is goes (like "or _Cancel_") so that users know what to expect. As Henning remarked in the other review, the text of the action will vary in size and that could make the list of several open rows hard to scan.
| Michael Nelson (michael.nelson) wrote : | # |
Hi Guilherme,
Here's an updated screencast based on your UI review:
http://
Let me know if it's what you were thinking.
| Guilherme Salgado (salgado) wrote : | # |
That works really nice, thanks for doing it, Michael. It'd be important to try and make the default radio button be initially selected on chromium as well, but if it turns out to be too tricky, maybe you can just file a bug for now.
| Curtis Hovey (sinzui) wrote : | # |
This looks great. Thanks Michael and Salgado for doing such a good job on this.
| Henning Eggers (henninge) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
thank you for this cool feature. I don't see any problems with your branch
just a few suggestions some of which we already discussed in IRC
review approve code
Cheers,
Henning
> === modified file 'lib/canonical/
> === modified file 'lib/canonical/
> === modified file 'lib/canonical/
> --- lib/canonical/
> +++ lib/canonical/
> @@ -526,7 +526,27 @@
> return decoded_qs
>
>
> -class BasicLaunchpadR
> +class LaunchpadBrowse
> + """A mixin for classes that share some method implementations."""
We already talked about how senseless this comment is ... Can you please
improve it?
> +
> + def getRootURL(self, rootsite):
> + """See IBasicLaunchpad
> + if rootsite is not None:
> + assert rootsite in allvhosts.configs, (
> + "rootsite is %s. Must be in %r." % (
> + rootsite, sorted(
> + root_url = allvhosts.
> + else:
> + root_url = self.getApplica
> + return root_url
> +
> + @property
> + def is_ajax(self):
> + """See `IBasicLaunchpa
> + return 'XMLHttpRequest' == self.getHeader(
I was just wondering: How much of a standard is the "X-Requested-With" header?
Is there a fall-back if browser does not send it?
> +
> +
> +class BasicLaunchpadR
> """Mixin request class to provide stepstogo."""
>
> implements(
> @@ -581,24 +601,8 @@
> return get_query_
>
>
> -class LaunchpadBrowse
> - """A mixin for classes that share some method implementations."""
> -
> - def getRootURL(self, rootsite):
> - """See IBasicLaunchpad
> - if rootsite is not None:
> - assert rootsite in allvhosts.configs, (
> - "rootsite is %s. Must be in %r." % (
> - rootsite, sorted(
> - root_url = allvhosts.
> - else:
> - root_url = self.getApplica
> - return root_url
> -
> -
> class LaunchpadBrowse
> - NotificationReq
> - LaunchpadBrowse
> + NotificationReq
> """Integration of launchpad mixin request classes to make an uber
> launchpad request class.
> """
> @@ -1370,7 +1374,7 @@
>
>
> class PublicXMLRPCReq
> - ErrorReportRequest, LaunchpadBrowse
> + ErrorReportRequ
> """Request type for doing public XML-RPC in Launchpad."""
>
> def _createResponse
>
...
| Michael Nelson (michael.nelson) wrote : | # |
On Mon, Sep 27, 2010 at 7:49 PM, Henning Eggers
<email address hidden> wrote:
> Review: Approve code
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
> thank you for this cool feature. I don't see any problems with your branch
> just a few suggestions some of which we already discussed in IRC
Cheers Henninge, comments below.
>> === modified file 'lib/canonical/
>> --- lib/canonical/
>> +++ lib/canonical/
>> @@ -526,7 +526,27 @@
>> return decoded_qs
>>
>>
>> -class BasicLaunchpadR
>> +class LaunchpadBrowse
>> + """A mixin for classes that share some method implementations."""
>
> We already talked about how senseless this comment is ... Can you please
> improve it?
Yep - I didn't write it (just moved it), but have updated it to:
"""Provides methods used for both API and web browser requests."""
>> + @property
>> + def is_ajax(self):
>> + """See `IBasicLaunchpa
>> + return 'XMLHttpRequest' == self.getHeader(
>
> I was just wondering: How much of a standard is the "X-Requested-With" header?
> Is there a fall-back if browser does not send it?
It is sent by most ajax libraries when sending xhr requests. The above
implementation matches Django's implementation.
>> === modified file 'lib/canonical/
>> --- lib/canonical/
>> +++ lib/canonical/
>> @@ -358,6 +358,16 @@
>> retried_
>> 'Cookie, Authorization')
>>
>> + def test_is_ajax(self):
>
> Please split this test up:
> def test_is_
Done (test_is_
>> implements(
>> + schema = IDistroSeriesDi
>> + custom_
>> +
>> + @property
>> + def initial_
>> + """Ensure the correct radio button is checked for blacklisting."""
>> + if self.context.status in (
>> + DistroSeriesDi
>> + DistroSeriesDi
>> + ):
>
> My feel is that multi-line if statements are to be avoided at all costs. ;)
> They just read badly. You can construct the tuple first and use that in the if
> statement.
OK, that's much better.
>> + def test_show_
>> + # Blacklist options are shown if requested by an editor via
>> + # ajax.
>> + ds_diff = self.factory.
>> +
>> + # Without JS, even editors don't see blacklist options.
>> + with person_
>> + view = create_
>> + ds_diff, '+listing-
>> + self.assertFal
>
> Yes, as you mentioned, please split this test up as well.
Done - it's now 3 tests.
>> + def test_bl...

I forgot to mention, I've ventured slightly from that mockup after some earlier discussions with Henning... that's why 'Add to blacklist' on the mockup has been replaced by two separate links.