| 8b0ea2285c1327a686ff0b6ab245915e7fd20094 |
|
23-Dec-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Overhaul how we deal with related data in TKO -- test labels, test attributes, machine labels, and iteration results.
This has proven one of the trickiest areas of TKO. The first foray into this area was machine label headers, an early feature request implemented in a pretty ad-hoc manner in spreadsheet view which allowed them to be used as header fields. (Ironically, this was closest to the right approach on the server side, but I didn't appreciate it at the time. The original client-side implementation was a mess.) Next was filtering on test attributes and test labels, implemented with the include_labels, exclude_labels, include_attributes_where, and exclude_attributes_where options. This server-side implementation supported filtering but not viewing, grouping or sorting at all. Furthermore, even the filtering support was weak -- it only supporting ORing of inclusion requests and ANDing of exclusion requests. The client-side implementation was still pretty messy but was moving towards correctness. Finally, support was recently added for viewing iteration results in table view, but
grouping and filtering were excluded since they would've been very difficult to fit into the design. This was again a limited server-side approach, though the client-side implementation continued improving, albeit still using the trouble "generator items" in the mutliple list selector widget.
When I started working on support for test iterations and attributes in TKO table view, I finally hit upon the right server-side approach: specify the attributes that you're interested in, have the server perform a separate JOIN for each one, so that there's now a new column for each one, NULL if the attribute didn't exist and having the attribute's value if it did. Once it's created as a normal column, the user can do selection, grouping, sorting and filtering using the regular mechanisms. Everything just works. (For labels, it's slightly different, since whether or not a label is attached to a test is a boolean value. I opted to have the column's value be either NULL or the name of the label.)
Well, not quite perfectly. MySQL lets us define column aliases in a SELECT which are then usable in GROUP BY and ORDER BY. They aren't however, usable in the WHERE clause, because certain select expressions may not exist at the time the WHERE is applied. (Our expressions happen to be fine, but MySQL will have none of it.) There's absolutely no way I can see to define aliases for use in the WHERE clause. And unfortunately, our current interface allows users to provide a WHERE clause directly, so we can't perform translations or substitutions. As a result, filtering must be performed a little differently for these fields. You can't just say <field_name> = "<value>", like you can for most fields. For test attributes and iteration results, you say <field_name>.value = "<value>". For test labels and machine labels, you say <field_name>.id IS [NOT] NULL.
The first part of this CL is changing the server to use this new approach. get_test_views() now accepts test_label_fields, test_attribute_fields, machine_label_fields, and iteration_result_fields parameters, which allow the user to add extra fields based on these data types.
At the same time, I've changed how the TKO web clients deals with these data types in a way that mirrors the new way of handling these features on the server. There is now a global widget for adding custom fields based on any of the four data types. Once one is created, it can be used just like any other field in spreadsheet view, table view, and the global condition. This vastly simplifies most pieces of the code that previously dealt with these features, and it greatly expands the available space of features. Where we formerly had spreadsheet grouping/filtering on machine labels, table viewing of iteration results, and limited filtering on test labels and attributes, we now have viewing, grouping sorting, and filtering on all four.
High-level changes involved:
Server side
* added code to TestViewManager to handle the new options for creating fields, documented them, and documented that these options are supported and the rest are deprecated (we can probably delete them but we should check, they might be in use)
* added thorough unit tests for all of the above. on a side note, i discovered a neat feature of SQLite where you can add any function you've defined at a callable function from SQL statements. I used this to add some functions emulating MySQL-only functions. This could be used to good effect elsewhere, but this CL is big enough :)
* got rid of now-obsolete code for machine_label_headers option and iteration views
Client side:
* made HeaderFields immutable. Mutable HeaderFields turned out to be way too much of a nightmare. Users can specify values for ParameterizedFields at creation time, and if they want to modify them, they can delete and add.
* made all parts of the application (namely SpreadsheetView (both header selectors), TableView, and CommonPanel) use a single global HeaderFieldCollection
* changed ParameterizedFieldListPresenter to handle the new job of allowing creation and deletion of any kind of ParameterizedField. This new widget replaces the label/attribute filtering widget in the CommonPanel -- I got rid of all the code for that widget.
* removed the now-obsolete code for "generator items" in the MultiListSelectPresenter.
* finally made TableView use HeaderSelect. Since HeaderSelect plays a more significant role and it's role is more unified, it made sense to finally do this (TableView was previously duplicating logic from HeaderSelect, which was only used in SpreadsheetView). Since the HeaderSelect used in TableView is much simpler than the one used in SpreadsheetView, I extracted a new class SpreadsheetHeaderSelect, using composition rather than inheritance (it didn't really follow an is-a relationship).
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@4049 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 3f2110914421a50e509e619e6e876e0af096144c |
|
19-Nov-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Fix the "swap" link in TKO spreadsheet view, at least partially. It was completely broken and now it works except when machine label headers are active. I did it in a way that moves towards a more correct design, by introducing a State class for the HeaderSelect presenter, which sort of acts as a model class. Nonetheless, I performed a minimal refactoring necessary to accomplish the goal cleanly. Possible next steps would be:
* introduce a State object for the ParameterizedFieldListPresenter, and make HeaderSelect.State include an instance of that state. This, if done properly, would fix the above-mentioned remaining bug with swapping.
* move functionality to the State object that belongs there. addHistoryArguments() and handleHistoryArguments are two examples. It could also use accessors/mutators for its fields.
* change the interface of HeaderSelect to get rid of all the state accessors/mutators. Rather, there should be one pair of getter/setter for the saved state. Clients should perform other actions on the State object itself.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3958 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 16ab5250da1e2e5fb1549774063a8099ce4fdbb8 |
|
29-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Bugfix to ensure generated items are added to the MultiListSelectPresenter when necessary. Since there's no nice way in general for the clients to know if they've already added a generated item, made MultiListSelectPresenter allow multiple additions of a generated item. This ugliness should go away with the refactoring to formally separate state from presenter (mentioned in a previous change). Also, this change fixes an immediate bug where "Triage failures" wouldn't work (fixed by the change to TableView), but I made a parallel change to HeaderSelect, bringing similar code bits more in line to eventually (soon?) be consolidated.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3771 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| cb6ae7dca0f7eff64e3c9e413f0c30e008a2a6ae |
|
23-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Added ability to view iteration results in TKO Table View. The primary changes towards this end were:
* add IterationResultField, a ParameterizedField subclass for iteration results, and make TableView capable of generating and handling these fields
* add an IterationDataSource to make requests to get_iteration_views(), made TableView use this when iterations are selected
The feature is somewhat crude -- the name of the field is always something like "Iteration result 0" when it should really be something like "Iteration result: throughput" -- but I think it's a very functional first pass.
Unfortunately a lot of other changes were required, some quite ugly. This was due to two problems. First, TableView and HeaderSelect duplicate a lot of logic, but in slightly different ways. Unifying them will fix a lot of things. Second, there's a generally misguided use pattern field "names" and field "SQL names" in the code. That needs to be thought through and fixed.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3761 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 227a7a1d0484dcfa4c6d996a1c10e95437d059ef |
|
18-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
OK, one more refactoring -- this time, make TableView use HeaderFields (something I've wanted to do for a long time, there has been a TODO at the top of TableView for ages) and consolidate a lot more logic. Part of this was in the introduction of a new HeaderFieldCollection class, the rest was simple consolidation due to common use of HeaderField.
TableView and HeaderSelect still duplicate a lot of logic, sadly, although it's not immediately obvious from the code at this point. Eventually I'll fully consolidate those, but at this point I think I'm ready to implement the iteration view feature that I've been working towards the whole time.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3753 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 2b50af17e5fa602821a8917bbb9fa1ddb1176ee3 |
|
14-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Refactoring to extract and generalize all logic used for machine label headers. All the UI and presentation logic was tied closely to HeaderSelect, but the forthcoming feature to view iterations in table view will require the exact same logic in a different context. So in this change I extracted a generic superclass for MachineLabelField, ParameterizedField, and extracted all the relevant UI logic from HeaderSelect to a separate presenter, ParameterizedFieldListPresenter.
This is hopefully the last refactoring necessary before actually implementing the iteration view feature. And ideally, the test attribute view feature will follow on easily from that.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3712 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| d9e04c1a7950691cc348e70fa2470f8c414ae94f |
|
08-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Refactor code related to double list selecting widgets used in both SpreadsheetView and TableView. This will facilitate code reuse and extension for the feature to include test iterations/attributes in table view. It will also make unit testing possible and provides cleaner organization of the code.
The major effort here is to refactor the DoubleListSelector and HeaderSelect classes according to the Passive View pattern. There are passive view classes for the double list itself (DoubleListSelector, which will be renamed in a future CL to DoubleListSelectDisplay) and for the spreadsheet header selection UI (HeaderSelectorView, which I think I'll also rename to HeaderSelectorDisplay). There is a new class, MultiListSelectPresenter, which incorporates the presentation logic from DoubleListSelector as well as some of the logic from HeaderSelect related to switch between a single and double list. The remaining code in HeaderSelect was modified to use a MultiListSelectPresenter as much as possible, retaining only the code specific to the spreadsheet header selection (and the management of machine label headers will likely be extracted and generalized too, since that sort of thing will be necessary for test attributes/iterations). Finally, small modifications to Spreadsheet
View and TableView were required to have them use the new interfaces.
This change also introduces the ToggleLink widget, consolidating logic that had been applied in multiple places previously.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3667 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 8748ed29ef2a3a73c18cb387765d595db452256c |
|
05-May-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Fixed FindBugs warnings: changed some inner classes to static inner classes.
Risk: low
Visibility: low
Signed-off-by: James Ren <jamesren@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3092 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| c674d3ea684f75f3e05f5834b598050eb1c8856d |
|
12-Mar-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Support opening drilldown results in a new tab/window from spreadsheet and table views. When drilling down in spreadsheet and table views, either into a group or into test details for a single test, the user can open the resulting page in a new tab/window by control-clicking. I included what I believe is the proper code to support middle-clicking as well, but I could not see any browser support. I tried the GWT hosted mode browser and FF2 on linux, and FF3 and windows. I changed the cell selection combo to shift-click (I don't think anyone uses that feature anyway :-/).
The main technical challenge here was this: state is spread throughout a number of classes that make up the UI for spreadsheet and table views. Code for generating the history tokens is spread throughout those classes as well, using the state in each class. In order to open results in a new tab, the code needs to generate the history token for the new state while leaving the current UI unmodified. It would do this by calling functions to modify application state appropriately, then generate the new history token, and then revert to the previous application state before opening the new token in a new tab. However, since the UI widgets and state variables were all intertwined and spread throughout the code, this was impossible to do as the code was -- when we made calls to setup the new application state, the displayed UI would be modified.
To solve this, I modified a number of classes to implement updateStateFromView() and updateViewFromState() methods, making the separation between state and view more well-defined and explicitly controlled. I ensured that all state-modifying functions don't modify the view at all, and I made sure the history-generating functions only use state variables. Then I was able to make the code setup a new state, generate the new history token, and restore the old state without any visible changes in the UI.
I also modified CustomHistory and clients so that history tokens passing into and out of CustomHistory are dictionaries instead of strings. I find this a bit cleaner and (more importantly) it allows CustomHistory to safely check for token equality (checking strings is unsafe because ordering could change while content remains the same, thanks to the nondeterminism of iterating over a Map).
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@2876 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 869806f6a6063d4c5d83eed04ee63419d9ad8226 |
|
19-Nov-2008 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
When reading machine label values from history, ensure they get stored correctly and used.
git-svn-id: http://test.kernel.org/svn/autotest/trunk@2449 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 0fb9335593fed571e94b9242e4afdaf298153dfe |
|
27-Oct-2008 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Fix two bugs with machine label fields.
-ensure they get completely removed from data structures when they're removed.
-make the swap link work correctly by making selectItems handle MachineLabelHeaders.
git-svn-id: http://test.kernel.org/svn/autotest/trunk@2338 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| f248952e42ea33c34e41a49817e50f98c65c2716 |
|
24-Oct-2008 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Add feature to make spreadsheet header fields from combinations of machine labels. The user can create as many different machine-label-based fields as she wishes. For each field, she can enter a list of labels to be included. The field will then group on each combination of those labels.
-added new HeaderField abstract class with two implementations - SimpleHeaderField for normal fields and MachineLabelField for the new machine label fields
-made HeaderSelect capable of creating MachineLabelFields. In single header mode, selecting "Machine labels..." creates one, and deselecting it destroys it. In multiple header mode, each time "Machine labels..." is selected a new machine labels field is created, and deselecting one destroys it.
-made HeaderSelect display text boxes for each MachineLabelField for the user to input the label list.
-created HeaderSelect.addQueryParameters, moved fixed value logic into it (from SpreadsheetView.java), and put logic for machine label header in it.
-made TestGroupDataSource accept raw query parameters, and updated SpreadsheetDataProcessor to pass it through.
-modified SpreadsheetView to use HeaderFields throughout. Eventually other code (such as TableView) should be made to use them.
-added capability for ConditionTestSet to accept raw condition pieces. Eventually it will only work this way and I'll get rid of the field setting logic, since that's been moved to SimpleHeaderField.
-added ExtendedListBox class containing a bunch of utilities for ListBoxes that I've wanted for a long time. Several other parts of the code (DoubleListSelector, some of the graphing stuff) should be changes to use these utilities eventually.
-added ChangeListener support to DoubleListSelector
-made rpc interface accept a new "machine_label_headers" parameters, and added logic to tko_rpc_utils.py to construct SQL for machine label headers
-modified TestView manager to support a join into host labels
git-svn-id: http://test.kernel.org/svn/autotest/trunk@2331 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 8c9b839c2f5073a755952a8a865a04db3b2d4547 |
|
30-Sep-2008 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
add primitive support for fixed header values. fixed headers can be given as a comma- or whitespace-separated list of values. they will serve to both limit to results to the given values (something that could just as well be done with the WHERE clause, but I figured people would want this behavior) + force all given values to be included, even if it causes empty rows.
* add support to GroupDataProcessor + relevant RPCs in Django to support fixed header values, but *only* for single headers (i.e. no composite header support)
* add text box to GWT spreadsheet UI, accessible only in single-header mode. box accepts comma- or whitespace-separated list of values.
* add necessary code to process fixed headers + pass them to server, and to store in history URL
git-svn-id: http://test.kernel.org/svn/autotest/trunk@2204 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|
| 35444864c7b6f49865a7e17aa0052987b72e4728 |
|
08-Aug-2008 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Initial checkin of new TKO interface.
git-svn-id: http://test.kernel.org/svn/autotest/trunk@1959 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/HeaderSelect.java
|