Manning《GWT in Action》2007版：探索Web应用开发技术

需积分: 9 86 浏览量更新于2024-07-29 收藏 23.28MB PDF 举报

《Manning.GWT.in.Action.June.2007》是一本关于Google Web Toolkit (GWT) 的专业指南，由Manning Publications在2007年通过其早期访问计划(Manning Early Access Program, MEAP)出版。这本书主要针对GWT开发者，提供了一个深入且全面的学习路径，帮助读者掌握GWT的各个方面。第一部分，"Getting started"，旨在引导读者快速上手GWT。第1章介绍了GWT的基本概念和架构，让初学者对这个强大的JavaScript框架有初步了解。第2章指导读者创建一个默认的应用程序，展示了如何设置环境并构建基础项目。第3章则进一步探讨如何发展和扩展个人应用程序，包括架构设计和最佳实践。第二部分，"Building user interfaces"，着重于用户界面的开发。第4章讲解了如何使用GWT内置的Widgets（控件）来构建界面元素，这些控件提供了丰富的交互功能。第5章介绍Panels的使用，有助于组织和布局页面结构。第6章涉及事件处理，确保用户的操作能够被准确地响应。第7章阐述复合Widget的创建，通过组合基础组件构建复杂UI。第8章则深入讨论了JavaScript Native Interface (JSNI) 组件，允许开发者利用原生JavaScript进行更底层的定制。第9章介绍了模块化应用的重要性，如何有效地组织代码以提高可维护性和复用性。进入第三部分，"Advanced Techniques"，本书探讨了更高级的主题。第10章介绍了GWT-RPC，即GWT的远程过程调用技术，这对于构建分布式应用和与服务器端通信至关重要。第11章分析了客户端RPC架构，帮助读者理解GWT的异步数据交换机制。第12章讨论了经典的Ajax技术以及如何与HTML表单结合使用，确保用户体验的流畅。第13章则聚焦于JSON的交互，GWT如何实现与JSON数据的无缝集成，这对于API集成和数据交换非常实用。最后一章，第14章可能是对整个开发过程的总结或者对未来趋势的展望，可能涵盖了高级主题如性能优化、安全性和测试策略等。书中的作者还鼓励读者在Manning的在线论坛<http://www.manning-sandbox.com/forum.jspa?forumID=286>上分享评论和反馈，以便于持续更新和完善内容。《Manning.GWT.in.Action.June.2007》是一本既适合入门学习GWT，又适合有一定经验开发者深入研究的实用指南。

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=286

Communicating with GWT-RPC

The GWT-RPC mechanism allows you to send Java objects between the client and server with only a little

additional work on both the client and server sides. We get into the finer points of using GWT-RPC, and

show you some common usage patterns, in chapters 10 and 11, but for now we will stick to the basics.

You first define a service interface that will be implemented by the server. For example, if you were going

to create a password service it might look something like the following.

1.31 public interface PasswordService extends RemoteService {

1.32 Boolean changePassword (String user, String oldPass, String newPass);

1.33 }

Nothing too complex here. The interface simply defines one method for changing the user’s password. The

only requirement is that the interface must extend the RemoteService interface supplied by GWT. Next

comes the implementation of the server. Again, this is about as easy as it gets.

1.34 public class PasswordServiceImpl

1.35 extends RemoteServiceServlet

1.36 implements PasswordService {

1.37

1.38 public Boolean changePassword (String user, String old, String new) {

1.39 // add code here

1.40 }

1.41 }

The implementation implements the interface that we defined for our service, and extends the

RemoteServiceServlet. The RemoteServiceServlet is where all of the magic happens. This servlet receives the

data from the server, which we already mentioned must be text due to how the underlying XMLHttpRequest

object works, and deserializes the text data into Java objects. The Java objects are then passed to the

implemented changePassword() method for processing. On the return trip the RemoteServiceServlet

serialized the return value into text, which can then be sent back to the browser.

So far so good. We created a service interface, and coded the implementation on the server in a specific

way. Nothing too hard so far, and coding the client-side call is just as easy.

service.changePassword("jdoe", "abc123", "m@tr1x",

new AsyncCallback()

{

public void onSuccess (Object result) {

Window.alert("password changed");

}

public void onFailure (Throwable ex) {

Window.alert("uh oh!");

}

});

Here we call the changePassword() method, and in the call we include an additional AsyncCallback handler.

This is just like the RequestCallback that we used with the RequestBuilder, it handles the result that is passed

back from the server.

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=286

To be honest, we aren’t giving you the whole story, for example you may have noticed that we never

showed you the code to create the service object on the client-side. We did this because we want to provide

the flavor of what GWT-RPC provides without getting into some all of the details. For us, we found that

GWT-RPC is very easy to use once you have gone through a few iterations of using it, and when you

understand its limitations. We provide all of these details in chapters 10 and 11 so that you can take full

advantage GWT-RPC.

Following our diagram from figure 1.1, we move on to a topic that is somewhat related to RPC. Earlier

in the section we mentioned that RequestBuilder received a text response from the server, and we included

XML in the list of formats that the text might be in. Well, it would be difficult to use XML data without an

XML parser, so it is a good thing that GWT has that too.

Investigating GWT’s XML Parser

In the last five or so years XML has become a part of our daily lives as developers. The configuration of our

Java server uses an XML format, the RSS feeds that we consume and supply are XML, and often so are the

protocols that we use to communicate with remote services, like in the case of SOAP and XML-RPC. To

make it as simple as possible to deal with these data formats on the client browser, GWT provides a DOM

based XML parser. DOM based, or Document Object Model, XML parsers will consume the XML and

create an object tree. You can then use the DOM API to traverse the tree to read its contents.

GWT takes advantage of the fact that modern browsers have the ability to parse XML and create a DOM

tree. Because the parsing is done by the browser and not by GWT, you get the performance benefit of native

code execution. This code sample shows you how the XMLParser is used to create a Document object,

through which the entire DOM tree can be traversed.

Document doc = XMLParser.parse(responseText);

Element root = doc.getDocumentElement();

NodeList children = root.getChildNodes();

for (int i = 0; i < children.getLength(); i++) {

doSomethingWithNode(children.item(i));

}

From the Document object we can grab the root element, and in an XML document there can be only one.

From the root element we can iterate through the children, and their children, and so on. The GWT DOM

implementation is based on the standard provided by the W3C, the same people who standardized HTML.

In chapter 12 we use RequestBuilder with GWT’s XML parser to load a set of bookmarks from an XMl file

sitting on the server and present them as a menu list.

Next we continue with our exploration of the various GWT APIs and show you how GWT can manage

your browser history.

Managing the Browser History

One of the completely valid complaints of rich Internet applications is that it “breaks” the browser’s back

button. What we mean by this is that if you replace a piece of content on the web page dynamically with

JavaScript, the browser doesn’t count that as a page change. So what often happens is the user sees the

content of the page change, so they just assume that they can hit the back button in the browser to get back to

the previous content, but their assumption is false. This behavior is due to the fact that changing the content

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=286

of a page programmatically is a fairly new to many users, and they don’t understand it. In order to provide a

good experience for the user, we need to find a way of handling this so that it is transparent to the user.

The popular solution to this problem tends to be a little complicated to implement and use. It requires

adding a hidden frame to your page, and some amount of scripting to get it to work. In the case of GWT, all

of the hard work has been done for you. To access it, you will need to write an event handler that

implements the HistoryListener interface and register it with the History object. Here we register an instance

of a user defined class MyHistoryListener.

1.42 History.addHistoryListener(new MyHistoryListener());

With the listener registered you can track a “page change” by creating a new history token. A token is a

keyword that defines the content change. For example you might create the token “overview” for the page

with information about your company, and “reports” for a different page showing reporting information.

Note that when we say page, we don’t mean that the browser is loading different URL. This is GWT after all,

so a page could be content loaded by selecting a tab on a TabPanel, or selecting an option from a MenuBar.

1.43 History.newItem("overview");

1.44 History.newItem("reports");

Creating a new token will do two things. The first thing it does, which is invisible to you, is that a hidden

frame on the web page will be loaded with a new page. Because the hidden frame is loaded with a different

page, the browser will count this as a new page view, and add it to the history for the browser.

The second thing this does is call the onHistoryChanged() method of the HistoryListener to indicate a

content change.

1.45 public class MyHistoryListener implements HistoryListener {

1.46 public void onHistoryChanged (String historyToken) {

if (historyToken.equals("overview")) {

// display overview panel

}

else if (historyToken.equals("reports")) {

// display reports panel

}

Hopefully you can see how this will work now. Because the hidden frame has changed, clicking the back

button in the browser will change it back. This will in turn trigger another call to the HistoryListener with

the previous token. And don’t forget the browser’s forward button. Now that we have gone back into the

history, the forward button will move it back forward again. This behavior is exactly what the user expects.

We discuss the history mechanism a little more in chapter 4.

Now we move on to the last major API feature, and that is the testing framework. Being able to test

JavaScript code properly has proven to be a fairly difficult task due to the lack of good testing tools, and often

it is done poorly. GWT again makes our life easy by allowing you to test your GWT code with the Java

developers favorite testing framework, JUnit.

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=286

Introducing GWT’s JUnit Integration

It has always been a best practice to write automated tests for your code, and various frameworks have been

made available over the years to make the process less painful. JUnit is the most popular tool of this variety

used by Java developers and is integrated with many IDEs. Instead of creating a new framework for GWT

from scratch, GWT provides support for JUnit so that you don’t need to learn yet another testing framework.

To create a new test case, you create a class that extends GWTTestCase, which in turn extends JUnit’s

own TestCase class. You then need to implement just one required method, getModuleName(),

followed by any number of specific tests. The module name is used by GWT for locating the project

configuration file. We will delve into the details in chapter 16, but for now let’s look at a short example.

public class MathTest extends GWTTestCase

{

public String getModuleName ()

{

return "org.mycompany.MyApplication";

}

public void testAbsoluteValue ()

{

int absVal = Math.abs(-5);

assertEquals(5, absVal);

}

Here we only included one test, which verifies that the absolute value of -5 is 5. This is obviously true, but it

if were false the assertEquals() method would trigger an exception that will be reported by the JUnit test

runner.

Besides the usual JUnit style testing the GWT version also allows you to test RPC calls to the server.

Specifically GWT will start up its own version of Tomcat, execute your compiled GWT code, and test that

when your client-side code calls the server-side application that it gets the expected results. In short, it is

doing things that you couldn’t do otherwise without having someone sit in front of a browser to test your

application. No offense to real user testing, but if you have a large suite tests that you want to run over and

over, it is not realistic to always do this manually.

With the end of this section on JUnit, so does our look at the major features of GWT. Next we want to

show you how GWT compares to other technologies.

GWT vs. Other Solutions

GWT isn’t the first tool trying to make it easy to build rich Internet applications, and as web technologies

constantly evolve, it undoubtedly won’t be the last. In this section we take a look at several other technologies

that are often lumped into the same category as GWT and explain where the differences lie.

In each of the following sections, we provide a code example for creating a text box and a button. We

then fill the text box with the word “clicked” when the button is clicked with the mouse. Finally, we compare

the code example provided to our GWT reference implementation and discuss the important differences.

Figure 1.3 shows what the GWT reference implementation looks like in a web browser when the application

starts, and then after the action button is clicked.

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=286

Figure 1.3: Images of the GWT reference implementation of text box and button before and after the action button is

clicked

To begin, we need to examine our GWT reference implementation.

Listing 1.2 – An implementation of a simple Button event in GWT

final TextBox text = new TextBox(); | #1

text.setText("text box"); | #1

final Button button = new Button(); | #2

button.setText("Click Me"); | #2

button.addClickListener(new ClickListener() | #3

{ | #3

public void onClick (Widget sender) | #3

{ | #3

text.setText("clicked"); | #3

} | #3

}); | #3

Panel main = new FlowPanel(); | #4

RootPanel.get().add(main); | #4

main.add(text); | #5

main.add(button); | #5

(annotation) <#1 Creates text box>

(annotation) <#2 Creates button>

(annotation) <#3 Attaches event handler>

(annotation) <#4 Attaches main panel >

(annotation) <#5 Attaches widgets to panel >

This is the first example of GWT code that we have looked at, and it deserves a thorough explanation. #1 To

start, we create a new text box, which, once displayed in the browser, will look like a normal text box that you

might find in a form on the web. #2 Next we create a button and set the text to display on the button. Note

that at this point neither the text box nor button has been “attached” to the web page. #3 We then add an

event handler for the button. We do this by adding a click listener object, which will be called when a user

clicks the button. You will notice that the object we add as a listener is an anonymous class. If you haven’t

seen this type of Java construct before, it might seem a little unnatural at first, but all we are doing is creating

an new object that implements the interface ClickListener. #4 Next we add a panel to our window, and then

#5 add the text box and button to the panel.

When we run this GWT code, it renders an HTML page with a text box and button, and, when the

button is clicked, changes the text in the text box. In the following sections, we port this very simple code to

a few other frameworks and discuss how they differ from GWT. Note that we are making every attempt to

be unbiased as we describe the competing frameworks. We believe that each tool is different from the next,

and each has its own strengths and weaknesses.

剩余452页未读，继续阅读

shadowlux

粉丝: 1
资源: 55

Manning《GWT in Action》2007版：探索Web应用开发技术

manning.gwt.in.action.june.2007.part04

Manning.GWT.in.Practice.Apr.2008

manning.gwt.in.action.june.2007.part02

manning.gwt.in.action.june.2007.part03

manning.gwt.in.action.june.2007.part05

manning.gwt.in.action.june.2007.part06

manning.gwt.in.action.june.2007.part01

Manning GWT in Action June 2007(全)

GWT入门指南：从基础到高级技术探索

谷歌Web工具包实战：GWT入门与进阶

最新资源