Merge lp:~jtv/launchpad/extract-approval-js into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Jelmer Vernooij | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 11097 | ||||
Proposed branch: | lp:~jtv/launchpad/extract-approval-js | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
323 lines (+171/-86) 4 files modified
lib/lp/app/templates/base-layout-macros.pt (+2/-0) lib/lp/translations/javascript/importqueueentry.js (+159/-0) lib/lp/translations/templates/translationimportqueueentry-index.pt (+5/-83) lib/lp/translations/windmill/tests/test_import_queue.py (+5/-3) |
||||
To merge this branch: | bzr merge lp:~jtv/launchpad/extract-approval-js | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michael Nelson (community) | js | Approve | |
Jelmer Vernooij (community) | code | Approve | |
Review via email: mp+28852@code.launchpad.net |
Commit message
Extract translations import queue entry JS, fix chromium layout problem.
Description of the change
= Translations Import Queue Entry: Bug 589567 and Extraction =
The TAL for the translations import queue entry form contains javascript to make the form adjust dynamically to the choice of file type. Fields that don't apply to the selected file type disappear, and ones that do flash into view as soon as a new type is selected.
One small problem with this is that on Chromium, the fields that disappear continue to take up the same space, making for a very awkward form layout.
In this branch I move that javascript out into a .js file of its own. This opens the door to some improvements I'm planning to facilitate import queue review, as well as (I hope) future unit-testing of its individual functions, and either replacing getElemById with something generic or putting it in a more reusable place. I also took the opportunity to clean things up a bit.
Functionally, nothing changes apart from the fix to bug 589567 (the layout problem in Chromium), and the removal of some CSS classes (unused and undefined) that the JS assigned to all form fields as an implementation detail of its initialization algorithm. I fixed the Chromium issue by replacing the "visibility: collapsed" for hidden form rows with "display: none." For that I used a CSS class we already had: unseen.
On top of this I did make some fairly radical, but semantically neutral changes to how the code finds the DOM nodes it needs to show or hide, and how it shows or hides them.
First of these, the way it finds the nodes. The old code found and cached lists of DOM nodes for each file type as the form first rendered. This was quite complicated, and there were then two separate functions to adjust the form: one assumed that all fields were hidden and the other showed a green flash on fields that it made visible. The former was used for initial display (the node-lists initialization hid all fields as a side effect) and the other handles changes of the selected file type by the user.
The new code throws away all this optimization in favour of simplicity. A single method goes through the lists of relevant fields per file type, hides the irrelevant ones, and shows the relevant ones. The green flash is optional, controlled by an argument. There's no more caching of node lists. Only one function needs to know which fields are visible for which file types. For the predominant usage scenario, where the file type never changes, this is actually a lot less work than the optimized version—but I doubt it matters.
Second, there's how the nodes are manipulated. Instead of trying to do everything in a big smart loop I have several very simple loops iterating over the nodes to do one simple thing. This transformation is known as "loop fission." The loop is a bit complex so I extracted it into a function; the manipulation to be applied to each node (show, hide, animate with green flash) is passed in as another function.
The javascript is covered by a windmill test, which only needed a tiny update to the CSS it looks for to recognize hidden form rows plus some drive-by cleanups. To run the test:
{{{
./bin/test -vv -m lp.translations
}}}
I had some timeouts running this locally but it came through EC2 fine (and amazingly, it did actually run the tests). To run the above on EC2, do:
{{{
./utilities/ec2 test -o "-vv -m lp.translations
}}}
Q/A takes Rosetta or Launchpad admin rights, or membership of the Ubuntu Translations Coordinator team. Go to https:/
On the form, verify that only fields relevant to the file's type are shown. For instance, a Translations (PO) file will have a Language field but a Template (POT) will not. On the other hand a Template will have a Translation Domain field which a Translations file doesn't. The fields adjust when you select different file types, with new fields appearing in a green flash.
Jeroen
As I mentioned on IRC my JavaScript knowledge is a bit rusty.
I understand what you're doing and as far as I can tell it matches the JavaScript style guide. The tests fail here locally and ec2, which is a bit of a worry.
I would prefer somebody with a bit more experience reviewing Launchpad JavaScript code has a look as well. The fact that the test (spuriously?) fails is a blocker, it would be interesting to know why it is failing on some machines.