1. opensymphony
  2. xwork


xwork / docs / wikidocs / Core Concepts.html

        <title>Core Concepts</title>
	    <link rel="stylesheet" href="styles/site.css" type="text/css" />

	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
			    <td valign="top" class="pagebody">

				    <p class="paragraph"><h2 class="heading2"> XWork Core Concepts</h2></p>XWork is based on a number of core concepts that helps to explain how the framework works. The core concepts can be broken down into two parts: Architecture Concepts and Terminology.<p class="paragraph"><h2 class="heading2"> Architecture Concepts</h2><ul class="star">
<li> Explain Command Driven Architecture (in general)</li>
<li> Explain the implementation in XWork</li>
<h2 class="heading2"> Terminology</h2></p><h3 class="heading3"> Actions</h3><p class="paragraph">Actions are classes that get invoked in response to a request, execute some code and return a Result. Actions implement at a minimum a single method, execute(), that defines the entry point called by the framework. This method allows developers to define a unit of work that will be executed each time the Action is called.</p><h3 class="heading3"> ActionContext</h3><p class="paragraph">The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment. For more information, see ActionContext in <a href="Basics.html">Basics</a>.</p><h3 class="heading3"> Interceptors</h3><p class="paragraph">In XWork, Interceptors are objects that dynamically intercept Action invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent an action from executing. Interceptors provide developers a way to encapulate common functionality in a re-usable form that can be applied to one or more Actions. See <a href="Interceptors.html">Interceptors</a> for further details.</p><h3 class="heading3"> Stacks</h3><p class="paragraph">To handle the case where developers want to apply more than a single Interceptor to an Action, Stacks have been introduced. Stacks are an ordered list of Interceptors and/or other Stacks that get applied when an Action is invoked. Stacks centralize the declaration of Interceptors and provide a convenient way to configure mutiple actions.</p><h3 class="heading3"> Results</h3><p class="paragraph">Results are string constants that Actions return to indicate the status of an Action execution. A standard set of Results are defined by default: error, input, login, none and success.  Developers are, of course, free to create their own Results to indicate more application specific cases.</p><h3 class="heading3"> Result Types</h3><p class="paragraph">Result Types are classes that determine what happens after an Action executes and a Result is returned. Developers are free to create their own Result Types according to the needs of their application or environment. In WebWork 2 for example, Servlet and Velocity Result Types have been created to handle rendering views in web applications.</p><h3 class="heading3"> Packages</h3><p class="paragraph">Packages are a way to group Actions, Results, Result Types, Interceptors and Stacks into a logical unit that shares a common configuration. Packages are similiar to objects in that they can be extended and have individual parts overridden by &quot;sub&quot; packages.</p><h3 class="heading3"> ValueStack</h3><p class="paragraph">The ValueStack is a stack implementation built on top of an OGNL core. The OGNL expression language can be used to traverse the stack and retrieve the desired object. The OGNL expression language provides a number of additional features including: automatic type conversion, method invocation and object comparisons. For more information, see the <span class="nobr"><a href="http://ognl.org/">OGNL Website<sup><img src="./icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="&gt;&gt;" border="0"/></sup></a></span>.</p><h3 class="heading3"> Components</h3><p class="paragraph">XWork provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to apply a design pattern known as <b class="strong">Inversion of Control</b> (or IoC for short). In a nutshell, the IoC pattern allows a parent object (in this case XWork&#039;s ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <em class="emphasis">enabler</em>). See <a href="Components.html">Components</a> for further details.</p>