nutritionistcornInternet και Εφαρμογές Web

14 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

90 εμφανίσεις


Asynchronous JavaScript and XML (Ajax) development is hard. Because of a number of
reasons: JavaScript can require a lot of specialized knowledge and discipline, browsers
have slightly different implementations and feature sets, tooling is sti
ll immature, and
debugging in multiple environments is problematic. All of these factors add up to
developers needing a vast knowledge of browser oddities and tricks to build and
manage large Ajax projects.

To help deal with these problems, a number of too
lkits and libraries have emerged.
Libraries like Dojo,, Ext JS, and the Yahoo User Interface Library (YUI)
provide enhanced core features to JavaScript. More advanced techniques, like those
used by Echo2, create an entire rendering layer in

the browser while executing
application code on the server side.

Google Web Toolkit (GWT) represents something different. GWT is a Java to JavaScript
compiler. It takes Java code and compiles it into JavaScript to be run in a browser.

GWT provides
a platform for RIAs

allowing the client to maintain state and even perform
computations locally, with a full data model, without requiring a trip to the server for
every update to the interface. This has many advantages for both the user and the

The user gets a more responsive application, and the developer can
distribute the load of the application.


Don't call GWT a framework. GWT hasn't been here for years, and a lot of components
people expect from "Framework" products aren't there
. Java web frameworks, like Struts
and WebWork, evolved from the lessons learned in traditional Java web development.
As such, they come with a style, a set of patterns, and expected ways of working, all of
which help developers see where to begin with the
ir applications. GWT doesn't have
that. When working with GWT as a developer, it's best to think of it as an analogue to the
Java Abstract Windowing Toolkit (AWT). It's the basis for your application frame
not the framework itself.

This can be conside
red a limitation, but it can also be seen as a well
focused starting
point. GWT doesn't try to dictate the development approach you'll use; rather, it aims to
provide the components you can begin with to create Ajax applications, or frameworks,
on your own
everal patterns for development should
be mitigating

concerns in this
area; the point here is that a toolkit isn't necessarily limiting

it's a starting point.

What GWT includes

The Google Web Toolkit provides a number of technologies for building Ajax
pplications: the GWT compiler, a UI layer, an RPC system, several additional utilities
that make the web tier easier to manage, and the GWT shell.


vs. other solutions

GWT vs. Swing

Swing is the standard toolkit for building GUI applications in Java. S
wing isn't typically
associated with web applications, but we are comparing Swing to GWT because the two
frameworks are similar in the way you write code for them.

For Swing developers, there are a few important differences between GWT and Swing.
First, th
e components that ship with GWT don't follow the Model View Controller (MVC)
pattern: No model object can be shared by multiple components to keep them in sync.
Second, GWT doesn't use layout managers to control the layout. Instead, you use
panels that hav
e built
in layout styles. For example, the GWT HorizontalPanel arranges
its child components left
right across the page, whereas the DockPanel lets you add
widgets to the panel in a similar fashion to the Swing's BorderLayout.

GWT vs. Echo2

Echo2 is ano
ther popular web toolkit in the same problem space as GWT, and it's similar
to GWT in how it's used to create the UI. You use the API to create instances of
components and then add them to the display.

Although both frameworks use similar APIs, they work i
n an entirely different fashion.
Applications written for Echo2 run on the server, not the client. With GWT, you compile
your Java source to JavaScript and run it on the browser. With Echo2, you compile your
Java source to Java class files and run them on
the server. This also means that when a
side event is triggered, it may need to be handled on the server.

The consequence is that an interface built with Echo2 needs to hit the server more often,
but it doesn't have to deal with an RPC API because t
he RPC happens all by itself. It
also means that Echo2 doesn't need to send all the JavaScript to the browser at once; it
sends only what it needs to given the current state of the application. Finally, you're tied
to using a Java application server becaus
e this is required to host an Echo2 application.

GWT vs. JavaServer Faces

JavaServer Faces (JSF) is a web framework for Java
based web applications. It uses
managed Java beans on the server, which represent the model, plus a set of tag
libraries that can b
e used with a JSP page to reference the properties of the model. In a
standard JSF implementation, all the processing is done on the server, and the web
page reloads for each transaction. The fact that the page needs to reload for each
transaction doesn't
make JSF a viable rich client for built
in components, but with
additional effort it's possible.

JSF is different from GWT in that JSF provides little in the way of support for rich client
side functionality. It's possible to build reusable client
side co
mponents by doing some of
the work in JavaScript, but custom components have little reuse value. Because JSF
integrates with the client side, it's in competition with GWT, but there is some potential
for integrating the two

GWT vs. Ruby on Rails

The title

of this section is a little misleading because GWT and Ruby on Rails don't
compete, although they overlap in some respects. Ruby on Rails is a rapid development
framework that uses the Ruby language. It provides the server side of the equation and
is spec
ifically designed to handle a lot of the back
end work automatically for you. On
the client side, Ruby on Rails provides some support for Ajax, allowing you to use the
Java equivalent of a tag library in your HTML code. The end result is that Ruby on Rails

can send data to the server triggered by a user action and display a response in the
page. However, it isn't designed for complex interactions between the client and server.

GWT is client
centric, and most of what GWT does is on the client side of the pic
ture. It
lets you develop and display widgets using Java and write Java handlers to trap user
triggered actions. GWT can communicate with the server as needed, which may be
driven by user interaction or perhaps a timed event. GWT then lets you compile all
Java code to JavaScript so that the program can be run in the browser. On the server,
GWT only provides a mechanism for serializing and deserializing Java objects so they
can be received from the browser and sent back; it doesn't get involved in other
of the server.

Instead of competition between GWT and Ruby on Rails, we find an opportunity for
integration. This is in part driven by the fact that GWT provides several nonproprietary
schemes for passing data between client and server. We're findi
ng that many developers
who are starting to use GWT are using non
Java technologies on the server and are
looking at GWT to provide only client
side functionality.


GWT help

to solve some of the hardships involved with developing complex
changes the way you write rich clients by allowing you to write web applications
the same way you write desktop applications with Swing. GWT provides an abstraction
on top of the HTML DOM, allowing you to use a single Java API without having to worry

differences in implementations across browsers.

Tools like Echo2 attempt to do this as well, but they require a Java application server to
serve the application. GWT lets you instead create an application that compiles
completely to JavaScript and can be
served by any web server. This allows GWT to be
easily integrated with existing applications no matter what type of server you're running.

An important part of what GWT has to offer is its toolset for making RPCs. It provides a
simple RPC mechanism for pas
sing Java objects between the client and server

you to pass custom beans. GWT also allows communication to non
Java applications
via the standard JSON.

GWT as a whole lets you develop web applications at a higher level of abstraction and
s the tools already available for the Java language.