摘录的Grails的首段,非常不错的一段

Have you ever wanted a Java web application framework that required less configuration? Maybe
one that magically reads your mind and guesses what you want to achieve based on the busi-
ness logic rather than mountains of surrounding configuration. The amount of work it takes to
develop web applications in current Java web application frameworks has seen a dramatic rise
in code-generation utilities whose sole purpose is to generate surrounding configuration or
jump-start application development. If you’re reading this book as a developer interested in
Grails I hazard a guess that you’ve experienced the often cumbersome multistep process it can
be to work with web frameworks on the Java platform.
     Trust me though, you’re not alone. The search has been on for years to transform the land-
scape of the way we develop web applications with the Java platform and extends way beyond
just the frameworks themselves, but into the entire stack. It started with the initial specification
of the much heralded Java 2 Enterprise Edition (J2EE) stack, described lovingly by Bruce Tate2
as an “elephant.” The specification created a configuration-heavy, time-consuming environ-
ment, and acknowledgement of these mistakes were made particular in the area of Enterprise
JavaBeans (EJB).

      Before the mistakes could be corrected, the open source community reacted with frame-
works such as Spring, inspired by Rod Johnson’s book J2EE Development Without EJB, allowing
simplified development models, while ease of use in the object-relational mapping (ORM)
arena was driven by simplified POJO (Plain Old Java Object) frameworks such as Hibernate.
      It was not, however, the statically typed Java world that prompted the real innovation in
web framework design. Dynamic languages were already gaining prominence in other arenas,
but thanks to frameworks such as Ruby on Rails (henceforth simply referred to as Rails), Django,
and TurboGears, particular focus has been placed on their usage as web application frameworks.
After years of being ridiculed as toys, dynamic languages finally started to turn heads and kick-
start a rethink into how web applications can be simplified.
      Built with scripting languages such as Ruby and Python, this new generation of web frame-
works introduced the concept of “convention over configuration” in an object-oriented
environment. Instead of configuring everything via reams of XML, the convention within the
files or code itself dictated how the application was configured. Suddenly there was no need to
configure, and with that, the time spent on a typical development cycle was dramatically reduced.
Given their dynamic nature, the frameworks in question provided the ability to save a particular
class or resource and have the changes automatically propagated without any need to restart
an application server. Applications could be developed with a save/reload paradigm, and state
could be maintained; agile and iterative development had finally arrived.
      Since much of the functionality of these frameworks can be configured and dispatched at
runtime, the available APIs are significantly richer and often more domain-specific.
      Scripting languages themselves have always been popular for the development of web
applications because of their ability to realize changes immediately (no deployment step) and
their often more simple and concise syntax. Unfortunately they’ve rarely been seen as appro-
priate for usage on large-scale systems, usually due to a lack of object-oriented features and
issues with performance and scalability and/or legacy integration.
      Given the advancements in the platforms in which these languages operate and the hard-
ware on which they are executing, these issues have become less and less of a problem. Modern,
dynamic virtual machines (VMs) suffer from fewer of these deficiencies and have become a real
viable alternative, attracting many Java developers away from the Java platform.

Over the past few years the web has seen significant change. The Internet bubble burst, search
became the doorway to the web, and the rise of weblogs and open information saw the web
become even more opinionated. On the technology front, one of the most significant changes
to occur was the appearance of web applications that come close to rivaling the desktop
environment. Web developers had long been dismissed as mere hackers compared to their
counterparts in the desktop GUI programming world. But this was all about to change, and it
all started with essentially one object: the XMLHttpRequest.
      The XMLHttpRequest object has, in reality, been around for quite some time. Microsoft
started the revolution by including it as a custom ActiveX object to support its Outlook web
access service that integrated with Microsoft’s Exchange Server.
      Essentially it allowed the client (the browser) to query the server without the necessity to
reload the whole page. It achieved this feat by sending an asynchronous request to the server
via JavaScript. Although, strictly speaking, anything could be sent and received using the tech-
nology, XML was the initial technique used. Web applications could suddenly be event-driven,use drag-and-drop, perform autocompletion that integrates with server components, and do
all sorts of fancy things previously only seen in frameworks such as Swing. Applications such as
Gmail and Flickr even prompted users to stop using their desktop equivalents for mail and
photo organization, respectively.
      Since then, the word Ajax (Asynchronous JavaScript and XML) was coined and the web
has been abuzz with it ever since; Web 2.0 was born. The significance of this technology cannot
be underestimated. It has brought capabilities to web browsers thought only possible in desktop
environments. However, it has also increased the complexity, development time, and expertise
required to develop web applications.
      Luckily, with this influx of software engineering expertise into the client-side programming
world, JavaScript libraries have advanced at a staggering pace, adopting object-oriented tech-
niques to create simple reusable components. However, it is not just the client side that has
had to adapt; a much unwanted side effect of Ajax applications is the increased number of requests
that they produce. Ajax applications are for the most part loathed by network administrators
because of the load placed on the servers, but equally undesirable for developers because the
frameworks and tools we know and love are designed around a sequential request/response
model.
      Furthermore, existing Java frameworks have followed the traditional develop-compile-
deploy paradigm, a process that becomes slower as the number of requests increase and the
size of the project grows. Since Ajax applications inevitably end up being larger, in terms of
project size, than traditional web applications, this has huge implications on the compilation
and packaging time required to deploy a web application.
      To compound these already significant factors, testing rich application flows started to
become problematic. With much of the state held on the client, having to reload your browser
due to an application restart could set you several steps back in any given use case. The reality
was that the frameworks needed to adapt. Adapting is not the easiest thing to achieve in the
statically typed world of the Java Virtual Machine (JVM) where classes tend to be compiled
once. This is in complete contrast to dynamic languages that follow either an interpreted model
or automatically update resources for you at run time.
      The timing of the arrival of Ajax was perfect for the aforementioned dynamic-language-
based frameworks as they began offering solutions that wowed developers with support for devel-
oping Ajax applications and automatic reloading. Tight integration with JavaScript libraries such
as Prototype and Script.aculo.us allowed developers to easily perform asynchronous requests,
implement element observers, and perform interesting effects.
      In addition, features such as the iterative nature of development, no configuration or deploy-
ment cycle, and the convention-based approach meant that it was an extremely appealing
environment to develop with.
      Are the changing times a sign of not only a shift in the way we build applications, but also
the technologies we use to build them? Is this the end of Java as we know it? And is Java venturing
down the road to become the next COBOL? Many believe so; but the reality is quite different.

Unfortunately, however wonderful these dynamic frameworks are, they remain inaccessible to
thousands upon thousands of organizations for one simple reason: they do not integrate seam-
lessly with Java. Java integration itself goes far beyond simply executing within the context of
the JVM. It means API integration, architectural integration (security, profiling, debugging, etc.),object model integration, Java Enterprise Edition integration, and knowledge and mindshare
integration (yes company X already has dozens of Java developers if not more).
     Organizations across the world have a significant investment in Java technology as a plat-
form for their business. They’ve invested in application servers, support contracts, training
materials, employees, and hardware optimized for the JVM. All of this amounts to too much to
just walk away from to embrace the latest hot framework.
     The Java industry is a huge multibillion dollar behemoth that encompasses not only web
applications but server applications, desktop applications, smart cards, handheld devices,
mobile phones, set-top boxes—this list could go on forever. Conferences dedicated to Java are
some of the largest technology events in the world, proving to be the envy of other technology
industries.
     The size of the industry is sometimes difficult to fathom and it’s built on the strength of the
platform—a platform that has ensured the Java language has more open source libraries than
any other language on the planet.
     Need a library to programmatically create PDF documents? You have FOP or iText. Want a
choice of web frameworks that cover every potential use case? Java has dozens. Need a platform
to build service-oriented architecture (SOA) applications? The Java platform has the solution
for you.
     For many, Java and its sibling in the enterprise world, Java Enterprise Edition, have been
the platform of choice, having reached an unrivalled level of maturity and industry support.
Java application servers have become robust, scalable managed environments with advanced
deployment capabilities, security controls, and web services integration.
     Unfortunately, with all this power, Java web applications can be a pain to develop when
compared to their dynamic rivals from Ruby, Python, and PHP. Much of the time involved in
creating one of these beasts is spent on configuration, the build process, and deployment. Java
developers have strived to create build automation tools that make this process easier, including
tools that generate source code. This has improved even further with the advent of Java 5 anno-
tations support. But developing Java web applications for the most part remains quite a complex,
configuration-heavy experience.
     Nevertheless it would be simply unjust if the Java community were denied access to a
framework with the same capability as those available on dynamic language platforms.
     Since there are several dynamic languages that run happily on top of the JVM, such as
Jython, JRuby, and Groovy, it seems imminently possible. Luckily the Java community tends to
take the good ideas and make them better; enter Grails.