Modified: websites/production/tapestry/content/tapestry-ioc-overview.html
==============================================================================
--- websites/production/tapestry/content/tapestry-ioc-overview.html (original)
+++ websites/production/tapestry/content/tapestry-ioc-overview.html Sat Aug 8
17:20:04 2015
@@ -62,103 +62,14 @@
<div class="clearer"></div>
<div id="breadcrumbs">
- <a href="index.html">Apache Tapestry</a> > <a
href="documentation.html">Documentation</a> > <a
href="user-guide.html">User Guide</a> > <a
href="ioc.html">IoC</a> > <a
href="tapestry-ioc-overview.html">Tapestry IoC Overview</a>
+ <a href="index.html">Apache Tapestry</a> > <a
href="documentation.html">Documentation</a> > <a
href="user-guide.html">User Guide</a> > <a
href="ioc.html">IOC</a> > <a
href="tapestry-ioc-overview.html">Tapestry IoC Overview</a>
<a class="edit" title="Edit this page (requires approval -- just ask on
the mailing list)"
href="https://cwiki.apache.org/confluence/pages/editpage.action?pageId=23338486";>edit</a>
</div>
<div id="content">
-<div id="ConfluenceContent">
-
-<h1 id="TapestryIoCOverview-TapestryIoCOverview">Tapestry IoC Overview</h1>
-
-<p>Even today, with the overwhelming success of <a shape="rect"
class="external-link" href="http://www.springframework.org"; >Spring</a> and the
rise of smaller, simpler approaches to building applications (in contrast to
the heavyweight EJB approach), many people still have trouble wrapping their
heads around Inversion of Control.</p>
-
-<p>Really understanding IoC is a new step for many developers. If you can
remember back to when you made the transition from procedural programming (in
C, or BASIC) to object oriented programming, you might remember the point where
you "got it". The point where it made sense to have methods on objects, and
data inside objects.</p>
-
-<p>Inversion of Control builds upon those ideas. The goal is to make code more
robust (that is, with fewer errors), more reusable and much easier to test.</p>
-
-<p>Prior to IoC approaches, most developers were used to a more
<em>monolithic</em> design, with a few core objects and a <code>main()</code>
method somewhere that starts the ball rolling. <code>main()</code> instantiates
the first couple of classes, and those classes end up instantiating and using
all the other classes in the system.</p>
-
-<p>That's an <em>unmanaged</em> system. Most desktop applications are
unmanaged, so it's a very familiar pattern, and easy to get your head
around.</p>
-
-<p>By contrast, web applications are a <em>managed</em> environment. You don't
write a main(), you don't control startup. You <em>configure</em> the Servlet
API to tell it about your servlet classes to be instantiated, and their life
cycle is totally controlled by the servlet container.</p>
-
-<p>Inversion of Control is just a more general application of this approach.
The container is ultimately responsible for instantiating and configuring the
objects you tell it about, and running their entire life cycle of those
objects.</p>
-
-<p>Web applications are more complicated to write than monolithic
applications, largely because of <em>multithreading</em>. Your code will be
servicing many different users simultaneously across many different threads.
This tends to complicate the code you write, since some fundamental aspects of
object oriented development get called into question: in particular, the use of
<em>internal state</em> (values stored inside instance variables), since in a
multithreaded environment, that's no longer the safe place it is in traditional
development. Shared objects plus internal state plus multiple threads equals an
broken, unpredictable application.</p>
-
-<p>Frameworks such as Tapestry – both the IoC container, and the web
framework itself – exist to help.</p>
-
-<p>When thinking in terms of IoC, <strong>small is beautiful</strong>. What
does that mean? It means small classes and small methods are easier to code
than large ones. At one extreme, we have servlets circa 1997 (and Visual Basic
before that) with methods a thousand lines long, and no distinction between
business logic and view logic. Everything mixed together into an untestable
jumble.</p>
-
-<p>At the other extreme is IoC: small objects, each with a specific purpose,
collaborating with other small objects.</p>
-
-<p>Using unit tests, in collaboration with tools such as <a shape="rect"
class="external-link" href="http://easymock.org/"; >EasyMock</a>, you can have a
code base that is easy to maintain, easy to extend, and easy to test. And by
factoring out a lot of <em>plumbing</em> code, your code base will not only be
easier to work with, it will be smaller.</p>
-
-<h2 id="TapestryIoCOverview-LivingontheFrontier">Living on the Frontier</h2>
-
-<p>Coding applications the traditional way is like being a homesteader on the
American frontier in the 1800's. You're responsible for every aspect of your
house: every board, every nail, every stick of furniture is something you
personally created. There <em>is</em> a great comfort in total self reliance.
Even if your house is small, the windows are a bit drafty or the floorboards
creak a little, you know exactly <em>why</em> things are not-quite perfect.</p>
-
-<p>Flash forward to modern cities or modern suburbia and it's a whole
different story. Houses are built to specification from design plans, made from
common materials, by many specializing tradespeople. Construction codes dictate
how plumbing, wiring and framing should be performed. A home-owner may not even
know how to drive a nail, but can still take comfort in draft-free windows,
solid floors and working plumbing.</p>
-
-<p>To extend the metaphor, a house in a town is not alone and self-reliant the
way a frontier house is. The town house is situated on a street, in a
neighborhood, within a town. The town provides services (utilities, police,
fire control, streets and sewers) to houses in a uniform way. Each house just
needs to connect up to those services.</p>
-
-<h2 id="TapestryIoCOverview-TheWorldoftheContainer">The World of the
Container</h2>
-
-<p>So the IoC container is the "town" and in the world of the IoC container,
everything has a name, a place, and a relationship to everything else in the
container. Tapestry calls this world "The Registry".</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="tapestry-ioc-overview.data/ioc-overview.png"></span></p>
-
-<p>Here we're seeing a few services from the built-in Tapestry IoC module, and
a few of the services from the Tapestry web framework module. In fact, there
are over 100 services, all interrelated, in the Registry ... and that's before
you add your own to the mix. The IoC Registry treats all the services
uniformly, regardless of whether they are part of Tapestry, or part of your
application, or part of an add-on library.</p>
-
-<p>Tapestry IoC's job is to make all of these services available to each
other, and to the outside world. The outside world could be a standalone
application, or it could be an application built on top of the Tapestry web
framework.</p>
-
-<h2 id="TapestryIoCOverview-ServiceLifeCycle">Service Life Cycle</h2>
-
-<p>Tapestry services are <em>lazy</em>, which means they are not fully
instantiated until they are absolutely needed. Often, what looks like a service
is really a proxy object ... the first time any method of the proxy is invoked,
the actual service is instantiated and initialized (Tapestry uses the term
<em>realized</em> for this process). Of course, this is all absolutely
thread-safe.</p>
-
-<p>Initially a service is <em>defined</em>, meaning some module has defined
the service. Later, the service will be <em>virtual</em>, meaning a proxy has
been created. This occurs most often because some other service
<em>depends</em> on it, but hasn't gotten around to invoking methods on it.
Finally, a service that is ready to use is <em>realized</em>. What's nice is
that your code neither knows nor cares about the life cycle of the service,
because of the magic of the proxy.</p>
-
-<p>In fact, when a Tapestry web application starts up, before it services its
first request, only about 20% of the services have been realized; the remainder
are defined or virtual.</p>
-
-<h2 id="TapestryIoCOverview-Classvs.Service">Class vs. Service</h2>
-
-<p>A Tapestry service is more than just a class. First of all, it is a
combination of an <em>interface</em> that defines the operations of the
service, and an <em>implementation class</em> that implements the interface.</p>
-
-<p>Why this extra division? Having a service interface is what lets Tapestry
create proxies and perform other operations. It's also a very good practice to
code to an interface, rather than a specific implementation. You'll often be
surprised at the kinds of things you can accomplish by substituting one
implementation for another.</p>
-
-<p>Tapestry is also very aware that a service will have dependencies on other
services. It may also have other needs ... for example, in Tapestry IoC, the
container provides services with access to Loggers.</p>
-
-<p>Tapestry IoC also has support for other configuration that may be provided
to services when they are realized.</p>
-
-<h2 id="TapestryIoCOverview-DependencyInjection">Dependency Injection</h2>
-
-<p>Main Article: <a shape="rect" href="injection.html">Injection</a></p>
-
-<div class="navmenu" style="float:right; background:#eee; margin:3px;
padding:3px">
-<div class="error"><span class="error">Error formatting macro: contentbylabel:
com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not
parse cql : null</span> </div></div>
-
-<p>Inversion of Control refers to the fact that the container, here Tapestry
IoC's Registry, instantiates your classes. It decides on when the classes get
instantiated.</p>
-
-<p>Dependency Injection is a key part of <em>realization</em>: this is how a
service is provided with the other services it needs to operate. For example, a
Data Access Object service may be injected with a ConnectionPool service.</p>
-
-<p>In Tapestry, injection occurs through constructors, through parameters to
service builder methods, or through direct injection into fields. Tapestry
prefers constructor injection, as this emphasizes that dependencies should be
stored in <strong>final</strong> variables. This is the best approach towards
ensuring thread safety.</p>
-
-<p>In any case, injection "just happens". Tapestry finds the constructor of
your class and analyzes the parameters to determine what to pass in. In some
cases, it uses just the parameter type to find a match, in other cases,
annotations on the parameters may also be used. It also scans through the
fields of your service implementation class to identify which should have
injected values written into them.</p>
-
-<h2 id="TapestryIoCOverview-Whycan'tIjustusenew?">Why can't I just use
<code>new</code>?</h2>
-
-<p>That's a common question. All these concepts seem alien at first. What's
wrong with <code>new</code>?</p>
-
-<p>The problem with new is that it rigidly connects one implementation to
another implementation. Let's follow a progression that reflects how a lot of
projects get written. It will show that in the real world, <code>new</code> is
not as simple as it first seems.</p>
-
-<p>This example is built around some real-world work that involves a Java
Messaging Service queue, part of an application performance monitoring
subsystem for a large application. Code inside each server collects performance
data of various types and sends it, via a shared JMS queue, to a central server
for collection and reporting.</p>
-
-<p>This code is for a metric that periodically counts the number of rows in a
key database table. Other implementations of MetricProducer will be responsible
for measuring CPU utilization, available disk space, number of requests per
second, and so forth.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public class TableMetricProducer implements MetricProducer
+<div id="ConfluenceContent"><p>Even today, with the overwhelming success of <a
shape="rect" class="external-link" href="http://www.springframework.org";
>Spring</a> and the rise of smaller, simpler approaches to building
applications (in contrast to the heavyweight EJB approach), many people still
have trouble wrapping their heads around Inversion of Control.</p><p>Really
understanding IoC is a new step for many developers. If you can remember back
to when you made the transition from procedural programming (in C, or BASIC) to
object oriented programming, you might remember the point where you "got it".
The point where it made sense to have methods on objects, and data inside
objects.</p><p>Inversion of Control builds upon those ideas. The goal is to
make code more robust (that is, with fewer errors), more reusable and much
easier to test.</p><p>Prior to IoC approaches, most developers were used to a
more <em>monolithic</em> design, with a few core objects and a
<code>main()</code> m
ethod somewhere that starts the ball rolling. <code>main()</code> instantiates
the first couple of classes, and those classes end up instantiating and using
all the other classes in the system.</p><p>That's an <em>unmanaged</em> system.
Most desktop applications are unmanaged, so it's a very familiar pattern, and
easy to get your head around.</p><p>By contrast, web applications are a
<em>managed</em> environment. You don't write a main(), you don't control
startup. You <em>configure</em> the Servlet API to tell it about your servlet
classes to be instantiated, and their life cycle is totally controlled by the
servlet container.</p><p>Inversion of Control is just a more general
application of this approach. The container is ultimately responsible for
instantiating and configuring the objects you tell it about, and running their
entire life cycle of those objects.</p><p>Web applications are more complicated
to write than monolithic applications, largely because of <em>multithreading</
em>. Your code will be servicing many different users simultaneously across
many different threads. This tends to complicate the code you write, since some
fundamental aspects of object oriented development get called into question: in
particular, the use of <em>internal state</em> (values stored inside instance
variables), since in a multithreaded environment, that's no longer the safe
place it is in traditional development. Shared objects plus internal state plus
multiple threads equals an broken, unpredictable application.</p><p>Frameworks
such as Tapestry – both the IoC container, and the web framework itself
– exist to help.</p><p>When thinking in terms of IoC, <strong>small is
beautiful</strong>. What does that mean? It means small classes and small
methods are easier to code than large ones. At one extreme, we have servlets
circa 1997 (and Visual Basic before that) with methods a thousand lines long,
and no distinction between business logic and view logic. Everyt
hing mixed together into an untestable jumble.</p><p>At the other extreme is
IoC: small objects, each with a specific purpose, collaborating with other
small objects.</p><p>Using unit tests, in collaboration with tools such as <a
shape="rect" class="external-link" href="http://easymock.org/"; >EasyMock</a>,
you can have a code base that is easy to maintain, easy to extend, and easy to
test. And by factoring out a lot of <em>plumbing</em> code, your code base will
not only be easier to work with, it will be smaller.</p><h2
id="TapestryIoCOverview-LivingontheFrontier">Living on the
Frontier</h2><p>Coding applications the traditional way is like being a
homesteader on the American frontier in the 1800's. You're responsible for
every aspect of your house: every board, every nail, every stick of furniture
is something you personally created. There <em>is</em> a great comfort in total
self reliance. Even if your house is small, the windows are a bit drafty or the
floorboards creak a little
, you know exactly <em>why</em> things are not-quite perfect.</p><p>Flash
forward to modern cities or modern suburbia and it's a whole different story.
Houses are built to specification from design plans, made from common
materials, by many specializing tradespeople. Construction codes dictate how
plumbing, wiring and framing should be performed. A home-owner may not even
know how to drive a nail, but can still take comfort in draft-free windows,
solid floors and working plumbing.</p><p>To extend the metaphor, a house in a
town is not alone and self-reliant the way a frontier house is. The town house
is situated on a street, in a neighborhood, within a town. The town provides
services (utilities, police, fire control, streets and sewers) to houses in a
uniform way. Each house just needs to connect up to those services.</p><h2
id="TapestryIoCOverview-TheWorldoftheContainer">The World of the
Container</h2><p>So the IoC container is the "town" and in the world of the IoC
container, eve
rything has a name, a place, and a relationship to everything else in the
container. Tapestry calls this world "The Registry".</p><p><span
class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image"
src="tapestry-ioc-overview.data/ioc-overview.png"></span></p><p>Here we're
seeing a few services from the built-in Tapestry IoC module, and a few of the
services from the Tapestry web framework module. In fact, there are over 100
services, all interrelated, in the Registry ... and that's before you add your
own to the mix. The IoC Registry treats all the services uniformly, regardless
of whether they are part of Tapestry, or part of your application, or part of
an add-on library.</p><p>Tapestry IoC's job is to make all of these services
available to each other, and to the outside world. The outside world could be a
standalone application, or it could be an application built on top of the
Tapestry web framework.</p><h2
id="TapestryIoCOverview-ServiceLifeCycle">Service
Life Cycle</h2><p>Tapestry services are <em>lazy</em>, which means they are
not fully instantiated until they are absolutely needed. Often, what looks like
a service is really a proxy object ... the first time any method of the proxy
is invoked, the actual service is instantiated and initialized (Tapestry uses
the term <em>realized</em> for this process). Of course, this is all absolutely
thread-safe.</p><p>Initially a service is <em>defined</em>, meaning some module
has defined the service. Later, the service will be <em>virtual</em>, meaning a
proxy has been created. This occurs most often because some other service
<em>depends</em> on it, but hasn't gotten around to invoking methods on it.
Finally, a service that is ready to use is <em>realized</em>. What's nice is
that your code neither knows nor cares about the life cycle of the service,
because of the magic of the proxy.</p><p>In fact, when a Tapestry web
application starts up, before it services its first request, only about
20% of the services have been realized; the remainder are defined or
virtual.</p><h2 id="TapestryIoCOverview-Classvs.Service">Class vs.
Service</h2><p>A Tapestry service is more than just a class. First of all, it
is a combination of an <em>interface</em> that defines the operations of the
service, and an <em>implementation class</em> that implements the
interface.</p><p>Why this extra division? Having a service interface is what
lets Tapestry create proxies and perform other operations. It's also a very
good practice to code to an interface, rather than a specific implementation.
You'll often be surprised at the kinds of things you can accomplish by
substituting one implementation for another.</p><p>Tapestry is also very aware
that a service will have dependencies on other services. It may also have other
needs ... for example, in Tapestry IoC, the container provides services with
access to Loggers.</p><p>Tapestry IoC also has support for other configuration
that may be provided to
services when they are realized.</p><h2
id="TapestryIoCOverview-DependencyInjection">Dependency Injection</h2><p>Main
Article: <a shape="rect" href="injection.html">Injection</a></p><div
class="navmenu" style="float:right; background:#eee; margin:3px; padding:3px">
+<div class="error"><span class="error">Error formatting macro: contentbylabel:
com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not
parse cql : null</span> </div></div>Inversion of Control refers to the fact
that the container, here Tapestry IoC's Registry, instantiates your classes. It
decides on when the classes get instantiated.<p>Dependency Injection is a key
part of <em>realization</em>: this is how a service is provided with the other
services it needs to operate. For example, a Data Access Object service may be
injected with a ConnectionPool service.</p><p>In Tapestry, injection occurs
through constructors, through parameters to service builder methods, or through
direct injection into fields. Tapestry prefers constructor injection, as this
emphasizes that dependencies should be stored in <strong>final</strong>
variables. This is the best approach towards ensuring thread safety.</p><p>In
any case, injection "just happens". Tapestry finds the construc
tor of your class and analyzes the parameters to determine what to pass in. In
some cases, it uses just the parameter type to find a match, in other cases,
annotations on the parameters may also be used. It also scans through the
fields of your service implementation class to identify which should have
injected values written into them.</p><h2
id="TapestryIoCOverview-Whycan'tIjustusenew?">Why can't I just use
<code>new</code>?</h2><p>That's a common question. All these concepts seem
alien at first. What's wrong with <code>new</code>?</p><p>The problem with new
is that it rigidly connects one implementation to another implementation. Let's
follow a progression that reflects how a lot of projects get written. It will
show that in the real world, <code>new</code> is not as simple as it first
seems.</p><p>This example is built around some real-world work that involves a
Java Messaging Service queue, part of an application performance monitoring
subsystem for a large application. Code in
side each server collects performance data of various types and sends it, via
a shared JMS queue, to a central server for collection and
reporting.</p><p>This code is for a metric that periodically counts the number
of rows in a key database table. Other implementations of MetricProducer will
be responsible for measuring CPU utilization, available disk space, number of
requests per second, and so forth.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class TableMetricProducer implements
MetricProducer
{
. . .
@@ -170,15 +81,8 @@ public class TableMetricProducer impleme
}
}
</pre>
-</div></div>
-
-<p>We've omitted some of the details (this code will need a database URL or a
connection pool to operate), so as to focus on the one method and it's
relationship to the QueueWriter class.</p>
-
-<p>Obviously, this code has a problem ... we're creating a new QueueWriter for
each metric we write into the queue, and the QueueWriter presumably is going to
open the JMS queue fresh each time, an expensive operation. Thus:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public class TableMetricProducer implements MetricProducer
+</div></div><p>We've omitted some of the details (this code will need a
database URL or a connection pool to operate), so as to focus on the one method
and it's relationship to the QueueWriter class.</p><p>Obviously, this code has
a problem ... we're creating a new QueueWriter for each metric we write into
the queue, and the QueueWriter presumably is going to open the JMS queue fresh
each time, an expensive operation. Thus:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class TableMetricProducer implements
MetricProducer
{
. . .
@@ -190,22 +94,10 @@ public class TableMetricProducer impleme
Metric metric = new Metric("app/clients", System.currentTimeMillis(),
rowCount);
queueWriter.sendMetric(metric);
}</pre>
-</div></div>
-
-<p>That's better. It's not perfect ... a proper system might know when the
application was being shutdown and would shut down the JMS Connection inside
the QueueWriter as well.</p>
-
-<p>Here's a more immediate problem: JMS connections are really meant to be
shared, and we'll have lots of little classes collecting different metrics. So
we need to make the QueueWriter shareable:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
- private final QueueWriter queueWriter = QueueWriter.getInstance();</pre>
-</div></div>
-
-<p>... and inside class QueueWriter:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public class QueueWriter
+</div></div><p>That's better. It's not perfect ... a proper system might know
when the application was being shutdown and would shut down the JMS Connection
inside the QueueWriter as well.</p><p>Here's a more immediate problem: JMS
connections are really meant to be shared, and we'll have lots of little
classes collecting different metrics. So we need to make the QueueWriter
shareable:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> private final QueueWriter queueWriter =
QueueWriter.getInstance();</pre>
+</div></div><p>... and inside class QueueWriter:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class QueueWriter
{
private static QueueWriter instance;
@@ -224,13 +116,8 @@ public class QueueWriter
}
}
</pre>
-</div></div>
-
-<p>Much better! Now all the metric producers running inside all the threads
can share a single QueueWriter. Oh wait ...</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
- public synchronized static getInstance()
+</div></div><p>Much better! Now all the metric producers running inside all
the threads can share a single QueueWriter. Oh wait ...</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public synchronized static getInstance()
{
if (instance == null)
{
@@ -239,21 +126,8 @@ public class QueueWriter
return instance;
}
</pre>
-</div></div>
-
-<p>Is that necessary? Yes. Will the code work without it? Yes –
<strong>99.9% of the time</strong>. In fact, this is a very common error in
systems that manually code a lot of these construction patterns: forgetting to
properly synchronize access. These things often work in development and
testing, but fail (with infuriating infrequency) in production, as it takes two
or more threads running simultaneously to reveal the coding error.</p>
-
-<p>Wow, we're a long way from a simple <code>new</code> already, and we're
talking about just one service. But let's detour into <em>testing</em>.</p>
-
-<p>How would you test TableMetricProducer? One way would be to let it run and
try to find the message or messages it writes in the queue, but that seems
fraught with difficulties. It's more of an integration test, and is certainly
something that you'd want to execute at some stage of your development, but not
as part of a quick-running unit test suite.</p>
-
-<p>Instead, let's split QueueWriter in two: a QueueWriter interface, and a
QueueWriterImpl implementation class. This will allow us to run
TableMetricProducer against a <em>mock implementation</em> of QueueWriter,
rather than the real thing. This is one of the immediate benefits of <em>coding
to an interface</em> rather than <em>coding to an implementation</em>.</p>
-
-<p>We'll need to change TableMetricProducer to take the QueueWriter as a
constructor parameter.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public class TableMetricProducer implements MetricProducer
+</div></div><p>Is that necessary? Yes. Will the code work without it? Yes
– <strong>99.9% of the time</strong>. In fact, this is a very common
error in systems that manually code a lot of these construction patterns:
forgetting to properly synchronize access. These things often work in
development and testing, but fail (with infuriating infrequency) in production,
as it takes two or more threads running simultaneously to reveal the coding
error.</p><p>Wow, we're a long way from a simple <code>new</code> already, and
we're talking about just one service. But let's detour into
<em>testing</em>.</p><p>How would you test TableMetricProducer? One way would
be to let it run and try to find the message or messages it writes in the
queue, but that seems fraught with difficulties. It's more of an integration
test, and is certainly something that you'd want to execute at some stage of
your development, but not as part of a quick-running unit test
suite.</p><p>Instead, let's split QueueW
riter in two: a QueueWriter interface, and a QueueWriterImpl implementation
class. This will allow us to run TableMetricProducer against a <em>mock
implementation</em> of QueueWriter, rather than the real thing. This is one of
the immediate benefits of <em>coding to an interface</em> rather than
<em>coding to an implementation</em>.</p><p>We'll need to change
TableMetricProducer to take the QueueWriter as a constructor parameter.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class TableMetricProducer implements
MetricProducer
{
private final QueueWriter queueWriter;
@@ -285,19 +159,8 @@ public class TableMetricProducer impleme
}
}
</pre>
-</div></div>
-
-<p>This still isn't ideal, as we still have an explicit linkage between
TableMetricProducer and QueueWriterImpl.</p>
-
-<p>What we're seeing here is that there are multple <em>concerns</em> inside
the little bit of code in this example. TableMetricProducer has an unwanted
<em>construction concern</em> about which implementation of QueueWriter to
instantiate (this shows up as two constructors, rather than just one).
QueueWriterImpl has an additional <em>life cycle concern</em>, in terms of
managing the singleton.</p>
-
-<p>These extra concerns, combined with the use of static variables and
methods, are a <em>bad design smell</em>. It's not yet very stinky, because
this example is so small, but these problems tend to multiply as an application
grows larger and more complex, especially as services start to truly
collaborate in earnest.</p>
-
-<p>For comparison, lets see what the Tapestry IoC implementation would look
like:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public class MonitorModule
+</div></div><p>This still isn't ideal, as we still have an explicit linkage
between TableMetricProducer and QueueWriterImpl.</p><p>What we're seeing here
is that there are multple <em>concerns</em> inside the little bit of code in
this example. TableMetricProducer has an unwanted <em>construction concern</em>
about which implementation of QueueWriter to instantiate (this shows up as two
constructors, rather than just one). QueueWriterImpl has an additional <em>life
cycle concern</em>, in terms of managing the singleton.</p><p>These extra
concerns, combined with the use of static variables and methods, are a <em>bad
design smell</em>. It's not yet very stinky, because this example is so small,
but these problems tend to multiply as an application grows larger and more
complex, especially as services start to truly collaborate in
earnest.</p><p>For comparison, lets see what the Tapestry IoC implementation
would look like:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class MonitorModule
{
public static void bind(ServiceBinder binder)
{
@@ -311,51 +174,7 @@ public class MonitorModule
}
}
</pre>
-</div></div>
-
-<p>Again, we've omitted a few details related to the database the
TableMetricProducer will point at (in fact, Tapestry IoC provides a lot of
support for configuration of this type as well, which is yet another
concern).</p>
-
-<p>The MonitorModule class is a Tapestry IoC module: a class that defines and
configures services.</p>
-
-<p>The bind() method is the principle way that services are made known to the
Registry: here we're binding a service interface to a service implementation.
QueueWriter we've discussed already, and MetricScheduler is a service that is
responsible for determining when MetricProducer instances run.</p>
-
-<p>The contributeMetricScheduler() method allows the module to
<em>contribute</em> into the MetricProducer service's <em>configuration</em>.
More testability: the MetricProducer isn't tied to a pre-set list of producers,
instead it will have a Collection<MetricProducer> injected into its
constructor. Thus, when we're coding the MetricProducerImpl class, we can test
it against mock implementations of MetricProducer.</p>
-
-<p>The QueueWriter service is injected into the contributeMetricScheduler()
method. Since there's only one QueueWriter service, Tapestry IoC is able to
"find" the correct service based entirely on type. If, eventually, there's more
than one QueueWriter service (perhaps pointing at different JMS queues), you
would use an annotation on the parameter to help Tapestry connect the parameter
to the appropriate service.</p>
-
-<p>Presumably, there would be a couple of other parameters to the
contributeMetricScheduler() method, to inject in a database URL or connection
pool (that would, in turn, be passed to TableMetricProducer).</p>
-
-<p>A new TableMetricProducer instance is created and contributed in. We could
contribute as many producers as we like here. Other modules could also define a
contributeMetricScheduler() method and contribute their own MetricProducer
instances.</p>
-
-<p>Meanwhile, the QueueWriterImpl class no longer needs the
<code>instance</code> variable or getInstance() method, and the
TableMetricProducer only needs a single constructor.</p>
-
-<h2 id="TapestryIoCOverview-AdvantagesofIoC:Summary">Advantages of IoC:
Summary</h2>
-
-<p>It would be ludicrous for us to claim that applications built without an
IoC container are doomed to failure. There is overwhelming evidence that
applications have been built without containers and have been perfectly
successful.</p>
-
-<p>What we are saying is that IoC techniques and discipline will lead to
applications that are:</p>
-
-<ul><li>More testable – smaller, simpler classes; coding to interfaces
allows use of mock implementations</li><li>More robust – smaller, simpler
classes; use of final variables; thread safety baked in</li><li>More scalable
– thread safety baked in</li><li>Easier to maintain – less code,
simpler classes</li><li>Easier to extend – new features are often
additions (new services, new contributions) rather than changes to existing
classes</li></ul>
-
-
-<p>What we're saying is that an IoC container allows you to work faster and
smarter.</p>
-
-<p>Many of these traits work together; for example, a more testable
application is inherently more robust. Having a test suite makes it easier to
maintain and extend your code, because its much easier to see if new features
break existing ones. Simpler code plus tests also lowers the cost of entry for
new developers coming on board, which allows for more developers to work
efficiently on the same code base. The clean separation between interface and
implementation also allows multiple developers to work on different aspects of
the same code base with a lowered risk of interference and conflict.</p>
-
-<p>By contrast, traditional applications, which we term <em>monolithic</em>
applications, are often very difficult to test, because there are fewer
classes, and each class has multiple concerns. A lack of tests makes it more
difficult to add new features without breaking existing features. Further, the
monolithic approach more often leads to implementations being linked to other
implementations, yet another hurdle standing in the way of testing.</p>
-
-<p>Let's end with a metaphor.</p>
-
-<p>Over a decade ago, when Java first came on the scene, it was the first
mainstream language to support garbage collection. This was very controversial:
the garbage collector was seen as unnecessary, and a waste of resources. Among
C and C++ developers, the attitude was "Why do I need a garbage collector? If I
call malloc() I can call free()."</p>
-
-<p>But now, most developers would never want to go back to a non-garbage
collected environment. Having the GC around makes it much easier to code in a
way we find natural: many small related objects working together. It turns out
that knowing when to call free() is more difficult than it sounds. The
Objective-C language tried to solve this with retain counts on objects and that
still lead to memory leaks when it was applied to object <em>graphs</em> rather
than object <em>trees</em>.</p>
-
-<p>Roll the clock forward a decade and the common consensus has shifted
considerably. Objective-C 2.0 features true garbage collection and GC libraries
are available for C and C++. All scripting languages, including Ruby and
Python, feature garbage collection as well. A new language <em>without</em>
garbage collection is now considered an anomaly.</p>
-
-<p>The point is, the life cycle of objects turns out to be far more
complicated than it looks at first glance. We've come to accept that our own
applications lack the ability to police their objects as they are no longer
needed (they literally lack the ability to determine <em>when</em> an object is
no longer needed) and the garbage collector, a kind of higher authority, takes
over that job very effectively. The end result? Less code and fewer bugs. And a
careful study shows that the Java memory allocator and garbage collector (the
two are quite intimately tied together) is actually <strong>more</strong>
efficient than malloc() and free().</p>
-
-<p>So we've come to accept that the <em>death concern</em> is better handled
outside of our own code. The use of Inversion of Control is simply the flip
side of that: the <em>life cycle and construction concerns</em> are also better
handled by an outside authority as well: the IoC container. These concerns
govern when a service is <em>realized</em> and how its dependencies and
configuration are injected. As with the garbage collector, ceding these chores
to the container results in less code and fewer bugs, and lets you concentrate
on the things that should matter to you: your business logic, your application
– and not a whole bunch of boilerplate plumbing!</p>
-</div>
+</div></div><p>Again, we've omitted a few details related to the database the
TableMetricProducer will point at (in fact, Tapestry IoC provides a lot of
support for configuration of this type as well, which is yet another
concern).</p><p>The MonitorModule class is a Tapestry IoC module: a class that
defines and configures services.</p><p>The bind() method is the principle way
that services are made known to the Registry: here we're binding a service
interface to a service implementation. QueueWriter we've discussed already, and
MetricScheduler is a service that is responsible for determining when
MetricProducer instances run.</p><p>The contributeMetricScheduler() method
allows the module to <em>contribute</em> into the MetricProducer service's
<em>configuration</em>. More testability: the MetricProducer isn't tied to a
pre-set list of producers, instead it will have a
Collection<MetricProducer> injected into its constructor. Thus, when
we're coding the MetricProducerImpl class
, we can test it against mock implementations of MetricProducer.</p><p>The
QueueWriter service is injected into the contributeMetricScheduler() method.
Since there's only one QueueWriter service, Tapestry IoC is able to "find" the
correct service based entirely on type. If, eventually, there's more than one
QueueWriter service (perhaps pointing at different JMS queues), you would use
an annotation on the parameter to help Tapestry connect the parameter to the
appropriate service.</p><p>Presumably, there would be a couple of other
parameters to the contributeMetricScheduler() method, to inject in a database
URL or connection pool (that would, in turn, be passed to
TableMetricProducer).</p><p>A new TableMetricProducer instance is created and
contributed in. We could contribute as many producers as we like here. Other
modules could also define a contributeMetricScheduler() method and contribute
their own MetricProducer instances.</p><p>Meanwhile, the QueueWriterImpl class
no longer nee
ds the <code>instance</code> variable or getInstance() method, and the
TableMetricProducer only needs a single constructor.</p><h2
id="TapestryIoCOverview-AdvantagesofIoC:Summary">Advantages of IoC:
Summary</h2><p>It would be ludicrous for us to claim that applications built
without an IoC container are doomed to failure. There is overwhelming evidence
that applications have been built without containers and have been perfectly
successful.</p><p>What we are saying is that IoC techniques and discipline will
lead to applications that are:</p><ul><li>More testable – smaller,
simpler classes; coding to interfaces allows use of mock
implementations</li><li>More robust – smaller, simpler classes; use of
final variables; thread safety baked in</li><li>More scalable – thread
safety baked in</li><li>Easier to maintain – less code, simpler
classes</li><li>Easier to extend – new features are often additions (new
services, new contributions) rather than changes to
existing classes</li></ul><p>What we're saying is that an IoC container allows
you to work faster and smarter.</p><p>Many of these traits work together; for
example, a more testable application is inherently more robust. Having a test
suite makes it easier to maintain and extend your code, because its much easier
to see if new features break existing ones. Simpler code plus tests also lowers
the cost of entry for new developers coming on board, which allows for more
developers to work efficiently on the same code base. The clean separation
between interface and implementation also allows multiple developers to work on
different aspects of the same code base with a lowered risk of interference and
conflict.</p><p>By contrast, traditional applications, which we term
<em>monolithic</em> applications, are often very difficult to test, because
there are fewer classes, and each class has multiple concerns. A lack of tests
makes it more difficult to add new features without breaking existi
ng features. Further, the monolithic approach more often leads to
implementations being linked to other implementations, yet another hurdle
standing in the way of testing.</p><p>Let's end with a metaphor.</p><p>Over a
decade ago, when Java first came on the scene, it was the first mainstream
language to support garbage collection. This was very controversial: the
garbage collector was seen as unnecessary, and a waste of resources. Among C
and C++ developers, the attitude was "Why do I need a garbage collector? If I
call malloc() I can call free()."</p><p>But now, most developers would never
want to go back to a non-garbage collected environment. Having the GC around
makes it much easier to code in a way we find natural: many small related
objects working together. It turns out that knowing when to call free() is more
difficult than it sounds. The Objective-C language tried to solve this with
retain counts on objects and that still lead to memory leaks when it was
applied to object <
em>graphs</em> rather than object <em>trees</em>.</p><p>Roll the clock forward
a decade and the common consensus has shifted considerably. Objective-C 2.0
features true garbage collection and GC libraries are available for C and C++.
All scripting languages, including Ruby and Python, feature garbage collection
as well. A new language <em>without</em> garbage collection is now considered
an anomaly.</p><p>The point is, the life cycle of objects turns out to be far
more complicated than it looks at first glance. We've come to accept that our
own applications lack the ability to police their objects as they are no longer
needed (they literally lack the ability to determine <em>when</em> an object is
no longer needed) and the garbage collector, a kind of higher authority, takes
over that job very effectively. The end result? Less code and fewer bugs. And a
careful study shows that the Java memory allocator and garbage collector (the
two are quite intimately tied together) is actually <
strong>more</strong> efficient than malloc() and free().</p><p>So we've come
to accept that the <em>death concern</em> is better handled outside of our own
code. The use of Inversion of Control is simply the flip side of that: the
<em>life cycle and construction concerns</em> are also better handled by an
outside authority as well: the IoC container. These concerns govern when a
service is <em>realized</em> and how its dependencies and configuration are
injected. As with the garbage collector, ceding these chores to the container
results in less code and fewer bugs, and lets you concentrate on the things
that should matter to you: your business logic, your application – and
not a whole bunch of boilerplate plumbing!</p><p> </p><p></p></div>
</div>
<div class="clearer"></div>
Modified: websites/production/tapestry/content/type-coercion.html
==============================================================================
--- websites/production/tapestry/content/type-coercion.html (original)
+++ websites/production/tapestry/content/type-coercion.html Sat Aug 8 17:20:04
2015
@@ -31,8 +31,6 @@
<link href='/resources/highlighter/styles/shThemeCXF.css' rel='stylesheet'
type='text/css' />
<script src='/resources/highlighter/scripts/shCore.js'
type='text/javascript'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'
type='text/javascript'></script>
- <script src='/resources/highlighter/scripts/shBrushXml.js'
type='text/javascript'></script>
- <script src='/resources/highlighter/scripts/shBrushPlain.js'
type='text/javascript'></script>
<script type="text/javascript">
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -175,7 +173,7 @@ short[] --> java.util.List
}
}));
</pre>
-</div></div><p></p></div>
+</div></div><p> </p><p></p></div>
</div>
<div class="clearer"></div>
Modified:
websites/production/tapestry/content/using-beaneditform-to-create-user-forms.html
==============================================================================
---
websites/production/tapestry/content/using-beaneditform-to-create-user-forms.html
(original)
+++
websites/production/tapestry/content/using-beaneditform-to-create-user-forms.html
Sat Aug 8 17:20:04 2015
@@ -32,7 +32,6 @@
<script src='/resources/highlighter/scripts/shCore.js'
type='text/javascript'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'
type='text/javascript'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'
type='text/javascript'></script>
- <script src='/resources/highlighter/scripts/shBrushPlain.js'
type='text/javascript'></script>
<script type="text/javascript">
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -188,7 +187,7 @@ DR=Dr.
<pre>zip-regexp=^\\d{5}(-\\d{4})?$
zip-regexp-message=Zip Codes are five or nine digits. Example: 02134 or
90125-1655.
</pre>
-</div></div><p>After a restart you'll see the ... the same behavior. But when
we start creating more complicated regular expressions, it'll be much, much
nicer to put them in the message catalog rather than inside the annotation
value. And inside the message catalog, you can change and tweak the regular
expressions without having to restart the application each time.</p><p>We could
go a bit further here, adding more regular expression validation for phone
numbers and e-mail addresses. We're also far from done in terms of further
customizations of the BeanEditForm component.</p><p>By now you are likely
curious about what happens <em>after</em> the form submits successfully
(without validation errors), so that's what we'll focus on next.</p><p>Next: <a
shape="rect" href="using-tapestry-with-hibernate.html">Using Tapestry With
Hibernate</a></p><hr><p></p></div>
+</div></div><p>After a restart you'll see the ... the same behavior. But when
we start creating more complicated regular expressions, it'll be much, much
nicer to put them in the message catalog rather than inside the annotation
value. And inside the message catalog, you can change and tweak the regular
expressions without having to restart the application each time.</p><p>We could
go a bit further here, adding more regular expression validation for phone
numbers and e-mail addresses. We're also far from done in terms of further
customizations of the BeanEditForm component.</p><p>By now you are likely
curious about what happens <em>after</em> the form submits successfully
(without validation errors), so that's what we'll focus on next.</p><p>Next: <a
shape="rect" href="using-tapestry-with-hibernate.html">Using Tapestry With
Hibernate</a></p><p> </p><p></p></div>
</div>
<div class="clearer"></div>
Modified:
websites/production/tapestry/content/using-tapestry-with-hibernate.html
==============================================================================
--- websites/production/tapestry/content/using-tapestry-with-hibernate.html
(original)
+++ websites/production/tapestry/content/using-tapestry-with-hibernate.html Sat
Aug 8 17:20:04 2015
@@ -32,7 +32,6 @@
<script src='/resources/highlighter/scripts/shCore.js'
type='text/javascript'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'
type='text/javascript'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'
type='text/javascript'></script>
- <script src='/resources/highlighter/scripts/shBrushPlain.js'
type='text/javascript'></script>
<script type="text/javascript">
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -199,7 +198,7 @@ public class Index
}
}
</pre>
-</div></div><p>Here, we're using the Hibernate Session object to find all
Address objects in the database. Any sorting that takes place will be done in
memory. This is fine for now (with only a handful of Address objects in the
database). Later we'll see how to optimize this for very large result
sets.</p><h2 id="UsingTapestryWithHibernate-What'sNext?">What's Next?</h2><p>We
have lots more to talk about: more components, more customizations, built-in
Ajax support, more common design and implementation patterns, and even writing
your own components (which is easy!).</p><p>Check out the many Tapestry
resources available on the <a shape="rect"
href="documentation.html">Documentation</a> page, including the <a shape="rect"
href="getting-started.html">Getting Started</a> and <a shape="rect"
href="frequently-asked-questions.html">FAQ</a> pages and the <a shape="rect"
href="cookbook.html">Cookbook</a>. Be sure to peruse the <a shape="rect"
href="user-guide.html">User Guide</a>, which provi
des comprehensive details on nearly every Tapestry topic. Finally, be sure to
visit (and bookmark) <a shape="rect" class="external-link"
href="http://jumpstart.doublenegative.com.au/jumpstart7/"; >Tapestry
JumpStart</a>, which provides a nearly exhaustive set of tutorials.</p></div>
+</div></div><p>Here, we're using the Hibernate Session object to find all
Address objects in the database. Any sorting that takes place will be done in
memory. This is fine for now (with only a handful of Address objects in the
database). Later we'll see how to optimize this for very large result
sets.</p><h2 id="UsingTapestryWithHibernate-What'sNext?">What's Next?</h2><p>We
have lots more to talk about: more components, more customizations, built-in
Ajax support, more common design and implementation patterns, and even writing
your own components (which is easy!).</p><p>Check out the many Tapestry
resources available on the <a shape="rect"
href="documentation.html">Documentation</a> page, including the <a shape="rect"
href="getting-started.html">Getting Started</a> and <a shape="rect"
href="frequently-asked-questions.html">FAQ</a> pages and the <a shape="rect"
href="cookbook.html">Cookbook</a>. Be sure to peruse the <a shape="rect"
href="user-guide.html">User Guide</a>, which provi
des comprehensive details on nearly every Tapestry topic. Finally, be sure to
visit (and bookmark) <a shape="rect" class="external-link"
href="http://jumpstart.doublenegative.com.au/jumpstart7/"; >Tapestry
JumpStart</a>, which provides a nearly exhaustive set of
tutorials.</p><p> </p><p></p></div>
</div>
<div class="clearer"></div>
