Use SearchControl and SearchForm of Google Search Ajax API

When using the Google Search Ajax API, we may sometimes what to add functions when user initiate a search or clear the search result. the SearchForm is designed to do this. It provides .setOnSubmitCallback(object, method) and .setOnClearCallback(object, method) to let developer define method to call when user search or clear search result. But can we use the SearchControl, which provides easy-to-use and nice wrapped searcher, along with the SearchForm? The answer is yes. Here is the example code of using them together.

function OnLoad() {
var searchControl = new google.search.SearchControl();
searchControl.addSearcher(new google.search.WebSearch());
searchControl.addSearcher(new google.search.ImageSearch());

var drawOptions = new google.search.DrawOptions();
drawOptions.setDrawMode(google.search.SearchControl.DRAW_MODE_TABBED);
drawOptions.setSearchFormRoot(document.getElementById
("searchcontrol"));
searchControl.draw(document.getElementById("containerResults"), drawOptions);

var searchForm = new google.search.SearchForm(true, document
.getElementById('searchcontrol'));
searchForm.setOnSubmitCallback(searchControl, function() {
this.execute(searchForm.input.value);
});
searchForm.setOnClearCallback(searchControl, function() {
searchForm.input.value = '';
searchControl.clearAllResults();
});
searchForm.execute(QueryString);
}
google.setOnLoadCallback(OnLoad);

The HTML code is

< id="searchcontrol">
< id="containerResults">

The point to collect this two part together is drawOptions.setSearchFormRoot(document.getElementById("searchcontrol"));, which tells the SearchControl where to look for the associated SearchForm. Another thing to notice is that, in the SearchForm.SetOnCallBack, the execute() method to call should be the one of the SearchForm, like this.execute(searchForm.input.value);, not the one of the SearchControl (searchControl.execute(searchForm.input.value);), otherwise, the method set to OnClearCallBack will not be called when user clear search result.

Things to notice when testing form on Wicket

Wicket, a Java-based web application framework, provides powerful tester to test the application. The tester can simulate activities of users on the web application. The form tester is a component of the tester, which use to test form behavior on the page. However, there are something one need to notice when using the form tester.

Let's look at this example.
We test a form in the Checkout page, which looks like this

Name
Street
Zip code
City
State	Alabama Nebraska

The test code is

FormTester formTester = tester.newFormTester("form");
formTester.setValue("name", "Philip");
formTester.setValue("street", "Main Street");
formTester.setValue("zipcode", "96822");
formTester.setValue("city", "Anchorage");
formTester.setValue("state-wmc:state", "Alaska");
formTester.submit();
tester.assertRenderedPage(Index.class);

But when run the test, the last assertion indicate that it still in the Checkout page. Did you find anything wrong? The problem lies in

formTester.setValue("state-wmc:state", "Alaska");

And the fix is

formTester.select("state-wmc:state", 1);

The reason is that, FormTester.setValue() method cannot be used to set the value of selection field, thus the "state-wmc:state" field is not filled, so when the form is submitted, an error of invalid value occurs. This is an usual mistake when using FormTester.

Additionally, in order to find out what goes wrong when the test fail, we can use the Tester.assertErrorMessages(String[]) to see the error message.

Final Summary of GSoC 2009

As the fall semester 2009 begins, the GSoC 2009 goes to an end. During it I again successfully complete the project to the excepted goal.

At the beginning of the project, problems of the Issue sensor and its data structure design draw me quite back from the original schedule. However, after I settle it down, the further process become amazingly smooth. It took me like 2~3 weeks to finish Issue DailyProjectData analysis, and another week for Telemetry, and, several minutes to put it into Software ICU! I again experience how a well designed extensible system can boost new developments upon it. Though I am the main developer of the Software ICU, I really have not much to do in previous development of DPD and Telemetry, so it is not my previous experience lead to the boost development.

To add Issue analysis to Software ICU only involves editing a single configuration XML file(I was adding to the default configuration, but it is OK to add to your own configuration, if the developer did not upgrade the code in time =P). The main thing to newcomer may be to find out which file to edit and where it is. I just found that there is no documentation about it on hackystat-ui-wicket. I will add it in soon. Another maybe issue is that, none of the current stream classifier looks to fit the conception of Issue analysis. On the other hand, I do not yet have clear idea of how the Issue stream should be indicate the performance of developers. This can be one of the future study of Issue analysis.

In conclusion, last year, I followed the path of extensible system design to build the system. This year, I experience the benefit of building a system that way, and I am so thankful that we have done it that way. I am pretty sure this will be the way I keep following from now.

Almost done in summer project

Till today, Telemetry analysis of Issue, and the Issue DailyProjectData page in Project Browser is finished. As the way Telemetry service and Telemetry page in Project Browser implement, the new issue telemetry chart will just show in Project Browser and no modify needed. That means most of expected feature of summer project is done. Only thing not yet finish is put Issue analysis into Software ICU.

What I need to do now most is to put Issue sensor in use in Hackystat's hudson service, so that daily issue data will be collected. When Issue Telemetry analysis available, Software ICU can easily utilize it by modifying the configuration xml file.

We are in good shape here.

Experiencing Telemetry

Work of the past week is on development of hackystat-analysis-telemetry, to include telemetry analysis of Issue data into Hackystat system. Deal to the well constructed system as example and the sufficient documents, it is again quite straight forward to the goal. However, during coding, I found the telemetry language is kind of weird.

The language defines Telemetry Charts using some redefined language components, such as Reducers, which generate stream point value from DPD analysis, and axis. In the Chart definition, after define the name and parameters, the kernel part will look like this:

chart Issue(member, status) = {
"Issue invocations",
(IssueStream(member, status), yAxisZeroBased("Issue Count"))
};

Then we need to define the Stream called IssueStream, and after parameter description, the kernel part look like this:

streams IssueStream(member, status) = {
"Issue counts for the given mode for this Project",
Issue(member, status)
};

The definition of Streams seems redundant to me because it add no additional information to the reducer. So why not using the reducer directly in the Chart definition? I think it will be cooler that the telemetry language can directly use normal reducer like DevTime to generate the member level chart, so that no need to write in Java the member level reducer again.

Now I am coding the test cases for the Issue Telemetry analysis, need to make up Issue data again.

Finish milestone to DPD

It is a critical week of the hackystat issue project that the functionalities from issue sensor up to DailyProjectData are ready to release, along with updated documentation found in
Ant Task Reference
SensorDataTypeSpecification
DPD API

The new build of Hackystat including these feature should be release very soon. And it will be deployed in our daily hudson build to start gathering issue data.

Next setp is to implement Telemetry analysis. Then put all these things into Project Browser, including Software ICU of course.

DPD almost done

Issue analysis for DailyProjectData is almost done. The process is quite straight forward with the existed analyzes as examples. There is nothing interesting to mention in my opinion. It contains a total count of open issue on the dpd data for convenient.

When coding for DPD, I actually found some bugs in issue sensor. When testing the sensordata parser, I realize I can makeup some issue instance as CSV for testing. It should be used in tests for issue sensor as well.

Just keep working.