In this lab project, you will work in pair-programming fashion on the objectives listed below. I will start by demonstrating some of the specific technical details using the projection system in Olin 326. Then you'll need to work as a pair, consulting me as needed. I've included an extra-credit objective you con optionally work on as well; it will help you understand the asynchronous client/server interaction.
Log into GitHub.com.
Create, on GitHub, your own fork of my Max-Hailperin/MCS-270-UI repository.
Import the Gack project from that repository into Eclipse, which will create a local clone of your repository.
Run the project as a Web Application. When the URL appears, you will need to right-click it and add Google Chrome as the browser to use, entering the location /Applications/Google Chrome.app in the appropriate field. Once the project has fully loaded into the browser, try it out.
Switch branches in Eclipse to the scrollingGreetings branch. (The first time you switch, you'll need to create this branch locally based on the remote (GitHub) branch of the same name. I'll demo this.)
Reload the browser window and try out this alternative version of the application.
Look at the source of the two versions to get some idea of how they work. I particularly recommend using one of the comparison tools to highlight the differences -- either the comparison tool in Eclipse's Team menu or the one on GitHub.
Change the code so as to implement yet another user interface idea, described here. The idea is to put each client/server greeting exchange into one entry of a StackPanel, with the most recent one on top of the stack. (This sort of reverse-chronological order is common in such contexts as blogs, Facebook news feeds, etc.) A StackPanel can contain any number of entries, but at each point, only one of them is shown in full; the others are reduced to just show a heading. Clicking on any heading changes which entry is revealed in full. The idea is to use the name that the user entered as the heading text, with the full reply from the server as what is revealed.
You'll find this easiest to do starting from the scrollingGreetings version because it is more similar. You can either continue work in that branch or create a third branch that builds off from it.
The fundamental change is to put the greetings in a StackPanel rather than a VerticalPanel. You'll also strip the information down to its essence, getting rid of the dividing rules and such identifying labels as "Sending name to the server" and "Server replies". Make sure you put the new entry at the top of the stack, which can be done by inserting it at position 0. So that the newly inserted entry is visible, you should both set it as the one that the StackPanel is showing and scroll to the top.
Make some other user interface change of your choice. This can be as little as adjusting or augmenting one of the CSS (cascading stylesheet) entries in war/SampleWebApplication.css. Or you could add or modify a bit more Java code, as well as perhaps some CSS to support your code. There is lots of information about CSS on the web, as well as some on paper in the little room next to the lab. As always, I am also glad to help.
In order to see how the onFailure part of the asynchronous call to the server works, you'll need to have the server fail. That's hard to arrange. However, any exception thrown by the server method counts as a failure, and the server method is already setup to throw an exception if the name is too short; it uses the same FieldVerifier.isValidName test as the client does. Because the client is already catching the short names, you ordinarily will never see this in action. Temporarily comment out the test in the client-side code (SampleWebApplication.java), reload the page in the browser, and observe the effect of a short name. Make sure you understand the code that displays the message. (There is nothing to turn in for this part.)
Extra credit: Because the call to the sever is asynchronous, the program can continue running in the browser between sending a request to the server and receiving the response. The sample web application as Google provided it takes essentially no advantage of this fact, but it does have a related bug. It disables the send button when it sends a request and re-enables it only once the response is back. With the send button disabled, there is very little a user can continue doing. However, the user can edit a new name into the name field. And, more troubling, the user can press the enter key in that field, which sends the new name to the server the same as the send button would, if it weren't disabled. Because the program only has one copy of the textToServerLabel and the serverResonseLabel, sending a second request while the first one is outstanding creates an interesting misbehavior. When the first response comes from the server, the dialog box will show the text sent to the server the second time, with the response that came the first time. Then, a moment later when the second reply comes, the dialog box will update to show the second response.
Normally, you wouldn't be able to see this behavior because calls to the local server built into Eclipse usually don't take very long. However, you can artificially create longer delays as described in the first item below. Then you can improve the situation in one or more of the ways listed. Feel free to do any or all.
To make the interval longer, put a call to Thread.sleep into GreetingServiceImpl.java so as to deliberately delay it. (For example, Thread.sleep(5000) would sleep for 5000 milliseconds, which is five seconds.) After making this change in the server-side code, you need to reload the server. You can do that by pressing the button with the two yellow arrows on the Development Mode tab in Eclipse.
You should be able to see that the user can edit the name field and press enter during the delay. In the original (dialog box) version, you should see the buggy behavior described above.
With the scrolling or stacked messages, I don't think the bug would arise, because each time a request is sent, fresh objects are created. Check me on this. Assuming this is right, I don't see any reason to disable the send button. That makes it hard for the user to queue up multiple requests, but in the scrolling or stacking version, queued requests shouldn't be any issue because the replies should all eventually return and be displayed. You could try this out, simply by leaving the send button enabled.
Alternatively, or additionally, you could debug the dialog-box version.
Another possibility would be to add some other user-interface feature that makes sense to continue operating while waiting for a response, so as to take more advantage of asynchrony.
Submit your work as before: commit it to your local repository, push it to your GitHub repository, and send me a pull request on GitHub.
Postscript: The sample web application was deliberately kept simple by having just one class on the client and one on the server. This isn't a good structure for realistic applications because it leads to low cohesion. For advice on a more suitable architecture, I suggest you read about Google's Model-View-Presenter architecture.