- Revision
- 201
- Author
- mauro
- Date
- 2007-06-30 06:16:48 -0500 (Sat, 30 Jun 2007)
Log Message
Renamed pluggable.html -> pluggability.html
Modified Paths
- trunk/distribution/src/site/content/action-methods.html
- trunk/distribution/src/site/content/i18n.html
- trunk/distribution/src/site/content/sitemap.xml
Added Paths
Removed Paths
Diff
Modified: trunk/distribution/src/site/content/action-methods.html (200 => 201)
--- trunk/distribution/src/site/content/action-methods.html 2007-06-30 11:02:35 UTC (rev 200) +++ trunk/distribution/src/site/content/action-methods.html 2007-06-30 11:16:48 UTC (rev 201) @@ -83,7 +83,7 @@ } ... -}</pre></div><dl><dt>Note:</dt><dd>DefaultActionMethod annotations are also used when utilizing ParaNamer. They are needed so Waffle can handle requests when no ActionMethod has been signalled.</dd></dl></div><h3>ActionMethod return types</h3><p>Waffle will react differently depending on what is returned, or thrown, from an <b>ActionMethod</b> after it has been invoked. Below we define define how each case is handled in the Waffle framework:</p><ul><li><b>View</b> - An ActionMethod which returns an instance of <i>org.codehaus.waffle.view.View</i> or <i>org.codehaus.waffle.view.RedirectView</i> will forward or redirect, respectively. By default Waffle assumes that each View defines the full URL the user is to be sent to. This behavior can be altered by definning a different implementation of the <i>org.codehaus.waffle.view.ViewResolver</i>. Waffle was built to be pluggable this is the first example of how Waffle components can be customized and configured. Read the section on <a href="" pluggability</a> for further details.</li><li><b>null or void</b> - When an ActionMethod has a return type of <i>void</i> or when your ActionMethod returns a <i>null</i> Waffle will simply redirect back to the referring page.</li><li><b>Exception</b> - When an exception is thrown Waffle will set the response status to 400 (BAD REQUEST) and then send the contents of the message directly to the requestor. This functionality is especially useful when handling Ajax type of requests.</li><li><b>Other</b> - All other objects will have their toString() method called and the resulting value will be sent back to the requestor. This is similar to how Exceptions are handled, without the response status being set to an error code. This is useful for Ajax type of requests. Imagine these type of ActionMethod returning HTML or JSON messages directly.</li></ul></div><h3>Caveat: Ambiguous methods</h3><p>Waffle determines which ActionMethod to invoke by examining the Controller with reflection. If your Controller contains an overloaded method (same name and same number of arguments) Waffle may not be able to determine which ActionMethod should be fired. For example assume you have the following two methods defined in an Controller:</p><div class="source"><pre>public void save(String name, Object object); +}</pre></div><dl><dt>Note:</dt><dd>DefaultActionMethod annotations are also used when utilizing ParaNamer. They are needed so Waffle can handle requests when no ActionMethod has been signalled.</dd></dl></div><h3>ActionMethod return types</h3><p>Waffle will react differently depending on what is returned, or thrown, from an <b>ActionMethod</b> after it has been invoked. Below we define define how each case is handled in the Waffle framework:</p><ul><li><b>View</b> - An ActionMethod which returns an instance of <i>org.codehaus.waffle.view.View</i> or <i>org.codehaus.waffle.view.RedirectView</i> will forward or redirect, respectively. By default Waffle assumes that each View defines the full URL the user is to be sent to. This behavior can be altered by definning a different implementation of the <i>org.codehaus.waffle.view.ViewResolver</i>. Waffle was built to be pluggable this is the first example of how Waffle components can be customized and configured. Read the section on <a href="" pluggability</a> for further details.</li><li><b>null or void</b> - When an ActionMethod has a return type of <i>void</i> or when your ActionMethod returns a <i>null</i> Waffle will simply redirect back to the referring page.</li><li><b>Exception</b> - When an exception is thrown Waffle will set the response status to 400 (BAD REQUEST) and then send the contents of the message directly to the requestor. This functionality is especially useful when handling Ajax type of requests.</li><li><b>Other</b> - All other objects will have their toString() method called and the resulting value will be sent back to the requestor. This is similar to how Exceptions are handled, without the response status being set to an error code. This is useful for Ajax type of requests. Imagine these type of ActionMethod returning HTML or JSON messages directly.</li></ul></div><h3>Caveat: Ambiguous methods</h3><p>Waffle determines which ActionMethod to invoke by examining the Controller with reflection. If your Controller contains an overloaded method (same name and same number of arguments) Waffle may not be able to determine which ActionMethod should be fired. For example assume you have the following two methods defined in an Controller:</p><div class="source"><pre>public void save(String name, Object object); public void save(String color, Map dictionary);</pre></div><p>Attempting to invoke the ActionMethod <b>method=save|hello|{dictionary}</b> will cause an <i>AmbiguousMethodSignatureException</i> to be thrown because Waffle will not be able to determine which of the <i>save</i> methods should be invoked. However, the ActionMethod <b>method=save|foo|bar</b> will invoke the first <i>save</i> method, <b>void save(String, Object)</b>, without incident. Why? Because the String value "bar" is not assignable (and cannot be automatically converted) to the <i>Map</i> class, so no ambiguity will exist.</p></div><h3>Method Interceptor</h3><p>Waffle also allows you to implement custom <i>MethodInterceptor</i>s that can "intercept" calls to ActionMethods. This allows you to do pre and post processing on ActionMethods (allowing for simple AOP type of functionality). MethodInterceptor can also be chained together cleanly and easily. See the <a href="" Interceptors</a> for further details.</p></div> </body> </html>
Modified: trunk/distribution/src/site/content/i18n.html (200 => 201)
--- trunk/distribution/src/site/content/i18n.html 2007-06-30 11:02:35 UTC (rev 200) +++ trunk/distribution/src/site/content/i18n.html 2007-06-30 11:16:48 UTC (rev 201) @@ -7,7 +7,7 @@ <body> - <h2>Internationalization (i18n)</h2><p>Waffle supports internationalization in two ways -</p><p>1) ApplicationResources.properties in the WAR file. This is the same file name that other web action frameworks use. The OS will load the most appropriate for the locale that happens to be in the WAR file.</p><p>2) A component <b>org.codehaus.waffle.i18n.DefaultMessageResourcesConfiguration</b> that provides default messages, can be swapped for your own implementation of <b>org.codehaus.waffle.i18n.MessageResources</b>. This is a more programatic way of handling message localisation.</p><p>It needs to be registered in <b>web.xml</b> (refer to <a href="" + <h2>Internationalization (i18n)</h2><p>Waffle supports internationalization in two ways -</p><p>1) ApplicationResources.properties in the WAR file. This is the same file name that other web action frameworks use. The OS will load the most appropriate for the locale that happens to be in the WAR file.</p><p>2) A component <b>org.codehaus.waffle.i18n.DefaultMessageResourcesConfiguration</b> that provides default messages, can be swapped for your own implementation of <b>org.codehaus.waffle.i18n.MessageResources</b>. This is a more programatic way of handling message localisation.</p><p>It needs to be registered in <b>web.xml</b> (refer to <a href="" </body> </html>
Copied: trunk/distribution/src/site/content/pluggability.html (from rev 191, trunk/distribution/src/site/content/pluggable.html) (0 => 201)
--- trunk/distribution/src/site/content/pluggability.html (rev 0) +++ trunk/distribution/src/site/content/pluggability.html 2007-06-30 11:16:48 UTC (rev 201) @@ -0,0 +1,26 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html> + <head> + <title>Pluggability</title> + </head> + <body> + + + <h2>Pluggability</h2><p>Waffle was designed to provide default functionality that should be suitable for most any application. However in order to provide complete flexibility Waffle allows its foundational components to be over-written with custom implementations. As an example Waffle uses Ognl for data binding properties from a users request to the actions. It is easy to plug-in your own <b>org.codehaus.waffle.bind.DataBinder</b> by adding the following to the applications <b>web.xml</b>:</p><div class="source"><pre><context-param> + <param-name>org.codehaus.waffle.bind.DataBinder</param-name> + <param-value>com.mycompany.MyDataBinder</param-value> +</context-param></pre></div><p>The <b>param-name</b> defines the interface of the component to be over-written and the <b>param-value</b> represents the implementing class. The following table lists all of the components that can currently be customized in Waffle:</p><table class="bodyTable"><tbody><tr class="a"><td align="left"><b>Key Interface</b></td></tr><tr class="b"><td align="left">org.codehaus.waffle.controller.ControllerDefinitionFactory</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.ActionMethodExecutor</td></tr><tr class="b"><td align="left">org.codehaus.waffle.action.ActionMethodResponseHandler</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.ArgumentResolver</td></tr><tr class="b"><td align="left">org.codehaus.waffle.bind.BindErrorMessageResolver</td></tr><tr class="a"><td align="left">org.codehaus.waffle.bind.DataBinder</td></tr><tr class="b"><td align="left">org.codehaus.waffle.context.ContextContainerFactory</td></tr><tr class="a"><td align="left">org.codehaus.waffle.view.DispatchHelper</td></tr><tr class="b"><td align="left">org.codehaus.waffle.i18n.MessageResources</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.MethodDefinitionFinder</td></tr><tr class="b"><td align="left">org.codehaus.waffle.validation.Validator</td></tr><tr class="a"><td align="left">org.codehaus.waffle.view.ViewDispatcher</td></tr><tr class="b"><td align="left">org.codehaus.waffle.view.ViewResolver</td></tr></tbody></table><p>Most application will never need to deal with any of these components. But it is nice to know that you can change any of the default behaviour if you so desire.</p></div><h2>Other components</h2><p>Waffle also allows you to plug-in your own custom components which don't need to extend or implement any Waffle components. This is easy to do by adding <b>context-param</b>'s to your <b>web.xml</b> file. Notice the <b>register:</b> prefix in the <i>param-name</i> node below. When Waffle runs across such <i>context-param</i> it will register it for use in your application. You can also use the prefix <b>registerNonCaching:</b> for those components that should be instantiated new each time.</p><div class="source"><pre><context-param> + <param-name>register:java.util.List</param-name> + <param-value>java.util.ArrayList</param-value> +</context-param></pre></div><p>For a more concrete example Waffle defines the interface <i>org.codehaus.waffle.bind.WaffleTypeConverter</i>. Implementations of this interface allows you to write custom conversions for a specific class type. The following is an example of how you can register your converters with Waffle. Waffle's <i>OgnlTypeConverter</i> is dependent on all <i>org.codehaus.waffle.bind.WaffleTypeConverter</i> that are registered in the <b>web.xml</b>. So the following example will provide 2 custom converters for use in your application.</p><div class="source"><pre><context-param> + <param-name>register:MoneyConverter</param-name> + <param-value>com.mycompany.MoneyTypeConverter</param-value> +</context-param> + +<context-param> + <param-name>register:ColorConverter</param-name> + <param-value>com.mycompany.ColorTypeConverter</param-value> +</context-param></pre></div><dl><dt>Note:</dt><dd>Everything registered with Waffle must be registered under a unique name. The interface name should be used when over-writing default or providing unique behaviour.</dd></dl> + </body> + +</html>
Deleted: trunk/distribution/src/site/content/pluggable.html (200 => 201)
--- trunk/distribution/src/site/content/pluggable.html 2007-06-30 11:02:35 UTC (rev 200) +++ trunk/distribution/src/site/content/pluggable.html 2007-06-30 11:16:48 UTC (rev 201) @@ -1,26 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html> - <head> - <title>Pluggability</title> - </head> - <body> - - - <h2>Pluggability</h2><p>Waffle was designed to provide default functionality that should be suitable for most any application. However in order to provide complete flexibility Waffle allows its foundational components to be over-written with custom implementations. As an example Waffle uses Ognl for data binding properties from a users request to the actions. It is easy to plug-in your own <b>org.codehaus.waffle.bind.DataBinder</b> by adding the following to the applications <b>web.xml</b>:</p><div class="source"><pre><context-param> - <param-name>org.codehaus.waffle.bind.DataBinder</param-name> - <param-value>com.mycompany.MyDataBinder</param-value> -</context-param></pre></div><p>The <b>param-name</b> defines the interface of the component to be over-written and the <b>param-value</b> represents the implementing class. The following table lists all of the components that can currently be customized in Waffle:</p><table class="bodyTable"><tbody><tr class="a"><td align="left"><b>Key Interface</b></td></tr><tr class="b"><td align="left">org.codehaus.waffle.controller.ControllerDefinitionFactory</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.ActionMethodExecutor</td></tr><tr class="b"><td align="left">org.codehaus.waffle.action.ActionMethodResponseHandler</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.ArgumentResolver</td></tr><tr class="b"><td align="left">org.codehaus.waffle.bind.BindErrorMessageResolver</td></tr><tr class="a"><td align="left">org.codehaus.waffle.bind.DataBinder</td></tr><tr class="b"><td align="left">org.codehaus.waffle.context.ContextContainerFactory</td></tr><tr class="a"><td align="left">org.codehaus.waffle.view.DispatchHelper</td></tr><tr class="b"><td align="left">org.codehaus.waffle.i18n.MessageResources</td></tr><tr class="a"><td align="left">org.codehaus.waffle.action.MethodDefinitionFinder</td></tr><tr class="b"><td align="left">org.codehaus.waffle.validation.Validator</td></tr><tr class="a"><td align="left">org.codehaus.waffle.view.ViewDispatcher</td></tr><tr class="b"><td align="left">org.codehaus.waffle.view.ViewResolver</td></tr></tbody></table><p>Most application will never need to deal with any of these components. But it is nice to know that you can change any of the default behaviour if you so desire.</p></div><h2>Other components</h2><p>Waffle also allows you to plug-in your own custom components which don't need to extend or implement any Waffle components. This is easy to do by adding <b>context-param</b>'s to your <b>web.xml</b> file. Notice the <b>register:</b> prefix in the <i>param-name</i> node below. When Waffle runs across such <i>context-param</i> it will register it for use in your application. You can also use the prefix <b>registerNonCaching:</b> for those components that should be instantiated new each time.</p><div class="source"><pre><context-param> - <param-name>register:java.util.List</param-name> - <param-value>java.util.ArrayList</param-value> -</context-param></pre></div><p>For a more concrete example Waffle defines the interface <i>org.codehaus.waffle.bind.WaffleTypeConverter</i>. Implementations of this interface allows you to write custom conversions for a specific class type. The following is an example of how you can register your converters with Waffle. Waffle's <i>OgnlTypeConverter</i> is dependent on all <i>org.codehaus.waffle.bind.WaffleTypeConverter</i> that are registered in the <b>web.xml</b>. So the following example will provide 2 custom converters for use in your application.</p><div class="source"><pre><context-param> - <param-name>register:MoneyConverter</param-name> - <param-value>com.mycompany.MoneyTypeConverter</param-value> -</context-param> - -<context-param> - <param-name>register:ColorConverter</param-name> - <param-value>com.mycompany.ColorTypeConverter</param-value> -</context-param></pre></div><dl><dt>Note:</dt><dd>Everything registered with Waffle must be registered under a unique name. The interface name should be used when over-writing default or providing unique behaviour.</dd></dl> - </body> - -</html>
Modified: trunk/distribution/src/site/content/sitemap.xml (200 => 201)
--- trunk/distribution/src/site/content/sitemap.xml 2007-06-30 11:02:35 UTC (rev 200) +++ trunk/distribution/src/site/content/sitemap.xml 2007-06-30 11:16:48 UTC (rev 201) @@ -20,7 +20,7 @@ <page>i18n.html</page> <page>registrar.html</page> <page>views.html</page> - <page>pluggable.html</page> + <page>pluggability.html</page> <page>binding-validation.html</page> <page>lifecycle.html</page> <page>ajax.html</page>
To unsubscribe from this list please visit:
