Date: 2004-09-04T15:25:46
   Editor: AndersSteinlein <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsJericho
   URL: http://wiki.apache.org/struts/StrutsJericho

   Struts-Jericho Wiki page. Current content from contrib/struts-jericho in CVS.

New Page:

Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x. 
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
codename to a proposal until the Community comes to a consensus. This proposal is 
called "Jericho" since it tries to tear-down the walls within the Struts architecture.

= General Description, Thoughts & Ideas =

Jericho proposes to open-up Struts by:
 * Declaring interfaces for all core components.
 * Providing working base implementations for all core components.
 * Encapsulating all path references within "Location" objects (aka Action``Forwards) 
and referring only to Locations from all other objects.
 * Providing additional extension points from core components so that the "Inversion 
of Control" pattern is fully realized. (e.g., a populate method for the Form``Handler.)
 * Providing "POJO" signatures that encapsulate servlet/portlet/soap behavior so that 
applications can be freed of servlet/portlet/soap semantics, if so desired. This 
strategy would also be applied to optional packages like Validator and Tiles.
 * Retain optional access to servlet/portlet objects so that applications can be free 
to do whatever they need to do.

== Backward compatibility ==

Jericho is a revolution and backward compatibility with prior versions of Struts is 
not the prime consideration. However, care is being taken to create a clear migration 
path, where practical, so that Jericho is available to the widest community possible.

== Taglibs/Tools ==

JSP taglibs and other presentation tools will be packaged separately from the core 
controller classes. Tags and tools can access the framework through a Struts``Context 
object passed through the request, rather than searching through the servlet or 
portlet contexts.

== ActionForms/Actions, et al ==

New implementations of Struts 1.x base classes will be provided. These classes will 
provide the Struts 1.x behavior, but will also implement the Jericho interfaces. (Much 
the same way perform was supported in Struts 1.1.)

These same techniques may be applied to provide adaptors for other frameworks, so as 
to make Struts Jericho available to the widest community possible.

== Configuration ==

The Jericho Configuration builds on the best aspects of Struts 1.2. The elements are 
different but still similar. Our goal is to allow a tool, such as a XLST processor, to 
migrate a Struts 1.2 DTD to Struts Jericho.

A second alternative might be to provide an alternate configuration loader that would 
map the Struts 1.2 elements to Struts Jericho objects at initialization.

== Servlet/Portlet/Soap/Mock support ==

Core components will implement signatures that reference a Struts``Context. 
Implementations of this interface can be backed by servlet, portlet, soap, or mock 
implementations as needed.

== Also under consideration ==

 * Services framework. Utilize Spring IoC, Hive``Mind, Avalon, Pico, Cornerstone, et 
cetera, to configure services.
 * Configuration testing. Integrate utility of Struts Test``Case, ideally configured 
from an XML configuration (a la Canoo Webtest).
 * Replace DTD with XML Schema.
 * Utilize protocols in resource paths. An mapped path would look like "mapping://foo" 
or a tiles forward would be "tiles://tilesdef". This would make it easy to plug in 
handlers to support different presentation engines.  If no protocol is specified, the 
path is handled as usual.
 * Combine form-bean and validator-form configurations. A single element would allow 
everything Struts knows about a form to be configured in one place.
 * Integrate Tiles definitions into core configuration.
 * Adopt Struts Workflow and Struts Menu as standard options, like Validator and Tiles.
 * Utilize Joda``Beans (http://www.joda.org/) as a foundation class for core 
components.
 * Load all configuration defaults form a core.properties file so that less is 
hardcoded, including a Plug``In class to bootstrap loading the core configuration.
 * Ensure that all framework objects in 2.x have consistent factory-based mechanisms 
to instantiate instances. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15604)

= Component Overview =

'''Configuration registry'''
 * At initialization, each request adapter (servlet, filter, et cetera), adds its 
configuration to a single registry at a global location under a unique key.

'''Command Context'''
 * Extends CoR Context to encapsulate framework members needed to process request and 
render response.

'''Request Adapter (servlet module, portlet, SOAP, mock)'''
 * Receives request from container (or Test``Runner)
 * Normalizes request path (masks pattern registered with container)
 * Creates context to wrap request and response objects
 * Adds reference to its configuration (stored in global registry)
 * Invokes Controller
 * When control returns, dispatches to Location (if any)

'''Controller'''
 * Receives context and selects the matching mapping
 * Adds reference to mapping instance to context
 * Sets mapping's default Location to context
 * Removes any expired messages from context
 * Invokes processor for mapping

'''Processor'''
 * Invokes series of methods ("Chain of Commands") to handle request. The default 
series includes:
  * Multipart
  * Locale
  * Content``Type
  * No``Cache
  * Pre``Process
  * Roles
  * Input``Handler
   * Cancel
   * Reset
   * Populate
   * Validate
   * Invalid
  * Mapping``Handler
   * Command | Script
    * Invoke business logic
    * Affect context state
    * Identify resource to render response
   * Location
    * Identify resource to render response

'''Exception``Handler'''
 * Intercept any Exception thrown by Processor and set Location to designated error 
page.

'''Tags/Tools'''
 * Reference Command Context (stored in request) to access framework members.

'''Server Pages'''
 * Utilize tags and tools to render dynamic data.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to