proposal -- netui command handling in the XmlHttpRequestServlet

[Eddie O'Neil <ek...@gmail.com>]

All--

  After working with the XmlHttpRequestServlet in NetUI a bit, I'd
like to propose that we make some changes to it in an effort to
improve its usability and to create a pluggable API that users can
extend and that works in more situations.

  Proposal below; let me know what you think.

Eddie

:::Overview:::

This proposal describes a command handling infrastructure that can be
used to handle requests to render markup or data to a client.  At a
high level, this will be done by implementing command handler classes
that are composed together using the Chain of Responsibility (CoR)
pattern.

Today, this functionality is implemented using a set of interceptors
that are wired into a "global" interceptor chain.  While this
implementation works, these interceptors should only run in the
XmlHttpRequestServlet, which would improve performance of all other
NetUI requests / forwards.

:::Proposal:::

The proposal here is to change the XmlHttpRequestServlet from a chain
of interceptors to a CoR pattern with commands.  This would include
making the following changes:

- add NetUI configuration JavaBeans that contain information for
wiring up commands and chains.  Chains will have names and be
configured like:

  <chains>
    <chain name="xmlhttprequest-cris">
      <command id="" classname=""/>
      ...
    </chain>
    ....
  </chains>

and framework code can discover a chain by name from the configuration
JavaBeans.

- the XmlHttpRequestServlet will use a chain to create a Context
object that is used for processing a request.  This allows the Context
object to be extended / overridden based on the type of request.

- the XmlHttpRequestServlet will use a chain to handle a request given
a Context object.  This ensures that requests will be handled by a
single command handler (which may compose other commands / chains) if
at all.

- the existing CRI objects will be morphed to follow the command API.

- in the OOTB NetUI configuration, the CRI chain will move from being
"global" interceptors to being commands in one of these named chains. 
This will improve the performance of each request / forward as the
CRIs won't run for each one.

Note, the configuration above is similar to that of Jakarta's
commons-chain.  At this time, I'd like to just have a small
implementation of CoR in NetUI rather than add a new JAR file with
versioning issues / blah blah blah.  :)  In the future, it should be
possible to configure the chains via commons-chain as well.

:::Interception:::

The notion of interception is still a useful one for NetUI as this
gives users the ability to wire arbitrary code together into a single
point in a request lifecycle.  Interception is the correct
approach here; consider the case where someone extending the framework
needs blocks A, B, and C to run consecutively.  Interception lets the
following happen:

  A -> B -> C

For example, it would be useful to have an interception point that
allowed users to expose additional objects to JSP 2.0 data binding by
adding them to the request.  Today, NetUI does this done in a fixed,
non-extensible location.

:::Commands in a Chain of Responsibility:::

Commands in a CoR serve a different purpose than interception.  While
both CoR and Interceptors are configured as just an ordered list of
classes, the execution of these lists is very different.  In general,
interception implements all of the items in the list; this is not the
case with CoR where commands are executed until one handles a request.
 For example, with three commands A, B, and C chained together as:

  A -> B -> C

If B handles the command, the CoR contract is that command C never
executes.  This pattern makes sense in the context of handling UI
rendering requests where multiple handlers may interfere with each
other if run independently.