Merge lp:~michael.nelson/launchpad/652838-select-diffs-for-syncing into lp:launchpad/db-devel
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Michael Nelson on 2010-10-05 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 9863 | ||||
| Proposed branch: | lp:~michael.nelson/launchpad/652838-select-diffs-for-syncing | ||||
| Merge into: | lp:launchpad/db-devel | ||||
| Diff against target: |
489 lines (+264/-51) 4 files modified
lib/canonical/launchpad/templates/launchpad-form.pt (+4/-3) lib/lp/registry/browser/distroseries.py (+76/-2) lib/lp/registry/browser/tests/test_series_views.py (+161/-43) lib/lp/registry/templates/distroseries-localdifferences.pt (+23/-3) |
||||
| To merge this branch: | bzr merge lp:~michael.nelson/launchpad/652838-select-diffs-for-syncing | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Curtis Hovey (community) | ui | 2010-10-05 | Approve on 2010-10-05 |
| Guilherme Salgado (community) | ui* | Approve on 2010-10-05 | |
| Jeroen T. Vermeulen (community) | code | 2010-10-05 | Approve on 2010-10-05 |
|
Review via email:
|
|||
Commit Message
Allow multiple differences to be selected for syncing.
Description of the Change
Overview
========
This branch fixes bug 652838 by adding (non-js) check boxes and the sync button for syncing differences.
Note: it does not add the actual sync operation itself, but just a stub action. Julian will be organising the actual operation at at later point (obviously before the feature is enabled).
UI demo
=======
http://
To demo locally:
Run http://
https:/
Details
=======
I had 2 issues, and one ongoing:
1) There doesn't seem to be a natural way to have a dynamic name for the action as required by the prototype at:
You'll see the solution in the view's initialize() method, but any better options would be gratefully accepted.
2) There doesn't seem to be a natural way to have dynamic vocabularies based on the view. I've looked at various ways that we've done this in the past, and none are ideal.
In translations a vocabulary factory is used (see lp.translations
In soyuz an extra field and widget is added to the form during view initialisation (ie. one that is not on the schema, see lp.soyuz.
I decided instead to include the field on the schema with an empty vocabulary, and then update the vocabulary during the view's setUpFields() call. But again, any better ideas are welcome.
3) Finally, two tests where I render the view and check tags are failing, it seems, because the traversal request/lp:person is returning None:
http://
I'm still looking into why this is. So far, tracked it down to the fact that, even within the person_logged_in context manager, the tests view.request.
To test
=======
bin/test -vvm test_series_views
I'll upload a quick screencast soon.
| Guilherme Salgado (salgado) wrote : | # |
The UI changes look good to me. I think it'd be nice to have an extra checkbox for selecting all/none versions, though.
| Michael Nelson (michael.nelson) wrote : | # |
> The UI changes look good to me. I think it'd be nice to have an extra
> checkbox for selecting all/none versions, though.
salgado: thanks. And yes, the all/none checkbox is included on the mockup, I hope to add it in a later branch, but it's not a priority right now.
| Curtis Hovey (sinzui) wrote : | # |
The behaviour is nice. Buttons should be in title case (except for subordinating conjunctions and commonly used prepositions):
Sync selected %s versions into => Sync Selected %s Versions into %s
This may look odd since the interpolated names may not be title case, but the user did that, not us.
| Leonard Richardson (leonardr) wrote : | # |
FYI, I just did a branch with dynamically-named buttons:
https:/
Basically, in the action code I created my own Actions object and copied in new Action objects. My Actions object was based on a class Actions object containing generic actions.
| Gary Poster (gary) wrote : | # |
I asked Leonard to comment on your (1), which he did, above. formlib actions are unpleasantly limited.
For (2), context-based vocabularies are what I expected you to use, but I see they are not sufficient for some reason. Without looking at the code more carefully, I don't know why. In their original usage, views are expected to be only a presentation of the context/model, so the context should be sufficient. I'm not sure why views are more than a presentation here, but would be interested to hear why. For the short term though, unless there's a nice way to refactor to actually use the context, hacks are the order of the day. :-(
| Michael Nelson (michael.nelson) wrote : | # |
On Tue, Oct 5, 2010 at 6:18 PM, Gary Poster <email address hidden> wrote:
> I asked Leonard to comment on your (1), which he did, above. formlib actions are unpleasantly limited.
Thanks Gary and Leonard.
>
> For (2), context-based vocabularies are what I expected you to use, but I see they are not sufficient for some reason. Without looking at the code more carefully, I don't know why. In their original usage, views are expected to be only a presentation of the context/model, so the context should be sufficient. I'm not sure why views are more than a presentation here, but would be interested to hear why. For the short term though, unless there's a nice way to refactor to actually use the context, hacks are the order of the day. :-(
In this case, the context is a distro series, the view is displaying a
batched (and soon to be filtered) list of items related to that
distroseries, which can be selected for an operation. Another similar
situation that comes to mind is copying packages for an archive. The
view's context is the archive, but the view lists the related batched
(and filtered) packages.
In both cases we've manually created a field with a vocabulary
matching the items listed on screen so that validation and the action
can only operate on the current batch of items. Does that make sense,
or is there a better way?
> --
> https:/
> You are the owner of lp:~michael.nelson/launchpad/652838-select-diffs-for-syncing.
>

It's just a crying shame that you have to go to these lengths to include dynamic information in your view. I looked for alternatives but didn't find any.
You mentioned that you'd talk to the zope people; I think that's a good idea. If only Zope's @action accepted a callable as an alternative to a string!