Fix wording in "Interceptor Chain Pattern" section.

This commit is contained in:
Evan Meagher 2011-10-03 20:39:18 -07:00 committed by Trustin Lee
parent 4ea375362f
commit 490fc249f8

View File

@ -160,14 +160,14 @@
<section> <section>
<title>Event Model based on the Interceptor Chain Pattern</title> <title>Event Model based on the Interceptor Chain Pattern</title>
<para> <para>
Well-defined and extensible event model is a must for an event-driven A well-defined and extensible event model is a must for an event-driven
application. Netty does have a well-defined event model focused on I/O. application. Netty has a well-defined event model focused on I/O. It
It also allows you to implement your own event type without breaking the also allows you to implement your own event type without breaking the
existing code at all because each event type is distinguished from existing code because each event type is distinguished from another by
each other by strict type hierarchy. This is another differentiator a strict type hierarchy. This is another differentiator against other
against other frameworks. Many NIO frameworks have no or very limited frameworks. Many NIO frameworks have no or a very limited notion of an
notion of event model; they often break the existing code when you try event model. If they offer extension at all, they often break the
to add a new custom event type, or just do not allow extension. existing code when you try to add custom event types
</para> </para>
<para> <para>
A &ChannelEvent; is handled by a list of &ChannelHandler;s in a A &ChannelEvent; is handled by a list of &ChannelHandler;s in a
@ -175,7 +175,7 @@
<ulink url="http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html">Intercepting Filter</ulink> <ulink url="http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html">Intercepting Filter</ulink>
pattern to give a user full control over how an event is handled and how pattern to give a user full control over how an event is handled and how
the handlers in the pipeline interact with each other. For example, the handlers in the pipeline interact with each other. For example,
you can define what to do when a data is read from a socket: you can define what to do when data is read from a socket:
</para> </para>
<programlisting>public class MyReadHandler implements &SimpleChannelHandler; { <programlisting>public class MyReadHandler implements &SimpleChannelHandler; {
public void messageReceived(&ChannelHandlerContext; ctx, &MessageEvent; evt) { public void messageReceived(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
@ -188,8 +188,7 @@
} }
}</programlisting> }</programlisting>
<para> <para>
You can also define what to do when other handler requested a write You can also define what to do when a handler receives a write request:
operation:
</para> </para>
<programlisting>public class MyWriteHandler implements &SimpleChannelHandler; { <programlisting>public class MyWriteHandler implements &SimpleChannelHandler; {
public void writeRequested(&ChannelHandlerContext; ctx, &MessageEvent; evt) { public void writeRequested(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
@ -202,7 +201,7 @@
} }
}</programlisting> }</programlisting>
<para> <para>
For more information about the event model, please refer to the For more information on the event model, please refer to the
API documentation of &ChannelEvent; and &ChannelPipeline;. API documentation of &ChannelEvent; and &ChannelPipeline;.
</para> </para>
</section> </section>