现在的位置: 首页 > 综合 > 正文

Convention Plugin

2013年06月30日 ⁄ 综合 ⁄ 共 10720字 ⁄ 字号小中大 ⁄ 评论关闭

Hello world

Now that the Convention plugin has been added to your application, let's start with a very simple example. This example will use an actionless result that isidentified鉴定by the URL. By default, the Convention plugin
assumes承担 that all of the results are stored in WEB-INF/content. This can be changed by setting the property struts.convention.result.path in
the Struts properties file to the new location. Don't worry about trailing slashes斜杠, the Convention plugin handles this for you. Here is our hello world JSP:

<html>
<body>
Hello world!
</body>
</html>

If you start Tomcat (or whichever J2EE container容器 you are using) and type in http://localhost:8080/hello-world into
your browser you should get this result:

WEB-INF/content/hello-world.jsp

Hello world!

This illustrates说明 that the Convention plugin will find results even when no actionexists存在 and it is all based on the URL passed to Struts.

Code behind hello world

Let's expand on详述 this example and add a code behind class. In order to do this we need to
ensure保证 that the Convention plugin is able to find our action classes. By default, the Convention plugin will find all action classes that implement com.opensymphony.xwork2.Action or
whose name ends with the word Action in specific packages.

These packages are located处于 by the Convention plugin using a search methodology. First the Convention plugin finds packages named struts, struts2, action or actions.
Any packages that match those names are considered the root packages for the Convention plugin. Next, the plugin looks at all of the classes in those packages as well as sub-packages and determines if the classes implement com.opensymphony.xwork2.Action or
if their name ends with Action (i.e. FooAction). Here's an example of a few classes that
the Convention plugin will find:

Classes

com.example.actions.MainAction
com.example.actions.products.Display (implements com.opensymphony.xwork2.Action)
com.example.struts.company.details.ShowCompanyDetailsAction

Each of the action classes that the plugin finds will be configured to
respond响应 to specific URLs. The URL is based on the package name that the class is defined in and the class name itself. First the plugin determines the namespace of the URL using the package names between the root package and the package
the class is defined in. For our examples above, the namespaces would be:

Namespaces

com.example.actions.MainAction -> /
com.example.actions.products.Display -> /products
com.example.struts.company.details.ShowCompanyDetailsAction -> /company/details

Next, the plugin determines the URL of the resource using the class name. It first removes the word Action from the end of the class name and then converts camel case names to dashes. In our example the full URLs would
be:

Full URLs

com.example.actions.MainAction -> /main
com.example.actions.products.Display -> /products/display
com.example.struts.company.details.ShowCompanyDetailsAction -> /company/details/show-company-details

You can tell the Convention plugin to ignore certain packages using the property struts.convention.exclude.packages. You can also tell the plugin to use different strings to locate root packages using the propertystruts.convention.package.locators.
Finally, you can tell the plugin to search specific root packages using the property struts.convention.action.packages.

Here is our code behind action class:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorld extends ActionSupport {
  private String message;

  public String getMessage() {
    return message;
  }

  public String execute() {
    message = "Hello World!";
    return SUCCESS;
  }
}

If you compile this class and place it into your application in the WEB-INF/classes, the Convention plugin will find the class and map the URL /hello-world to it. Next, we need to update our JSP to print out the message
we setup in the action class. Here is the new JSP:

WEB-INF/content/hello-world.jsp

<html>
<body>
The message is ${message}
</body>
</html>

If start up the application server and open up http://localhost:8080/hello-world in our browser, we should get this result:

Result

The message is Hello World!

Results and result codes

The Convention Plugin will pre-configure all of you action classes when Struts is started. By default, this configuration will also contain results for any JSPs that it can find within the application. The JSPs have an additional feature that allows different
JSPs to be used based on the result code of the action. Since action methods return Strings and these Strings are traditionally used to locate results for the action, the Convention plugin allows you to define different results based on the result code.

Building on our example from above, let's say we want to provide a different result if the result code from our action is the String zero rather than success. First, we update the action class to return
different result codes:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorld extends ActionSupport {
  private String message;

  public String getMessage() {
    return message;
  }

  public String execute() {
    if (System.currentTimeMillis() % 2 == 0) {
      message = "It's 0";
      return "zero";
    }

    message = "It's 1";
    return SUCCESS;
  }
}

Next, we add a new JSP to the application named WEB-INF/content/hello-world-zero.jsp. Notice that the first part of the file name is the same as the URL of the action and the last part of the name is the result code. This is the convention
that the plugin uses to determine which results to render. Here is our new JSP:

WEB-INF/content/hello-world.jsp

<html>
<body>
The error message is ${message}
</body>
</html>

Now, if you compile the action and restart the application, based on the current time, you'll either see the result from WEB-INF/content/hello-world.jsp or WEB-INF/content/hello-world-zero.jsp.

The result type is based on the extension of the file. The supported extensions are: jsp,ftl,vm,html,html. Examples of Action and Result to Template mapping:

URL	Result	File that could match	Result Type
/hello	success	/WEB-INF/content/hello.jsp	Dispatcher
/hello	success	/WEB-INF/content/hello-success.htm	Dispatcher
/hello	success	/WEB-INF/content/hello.ftl	FreeMarker
/hello-world	input	/WEB-INF/content/hello-world-input.vm	Velocity
/test1/test2/hello	error	/WEB-INF/content/test/test2/hello-error.html	Dispatcher

Chaining

If one action returns the name of another action in the same package, they will be chained together, if the first action doesn't have any result defined for that code. In the following example:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.Action;
import com.opensymphony.xwork2.ActionSupport;

public class HelloAction extends ActionSupport {
    @Action("foo")
    public String foo() {
        return "bar";
    }

    @Action("foo-bar")
    public String bar() {
        return SUCCESS;
    }
}

The "foo" action will be executed, because no result is found, the Convention plugin tries to find an action named "foo-bar" on the same package where "foo" is defined. If such an action is found, it will be invoked using the "chain" result.

XWork packages

Actions are placed on a custom XWork package which prevents conflicts. The name of this package is based on the Java package the action is defined in, the namespace part of the URL for the action and the parent XWork package for the action. The parent XWork
package is determined based on the property named struts.convention.default.parent.package(defaults to convention-default), which is a custom XWork package that extends struts-default.

Therefore the naming for XWork packages used by the Convention plugin are in the form:

XWork package naming

<java-package>#<namespace>#<parent-package>

Using our example from above, the XWork package for our action would be:

XWork package naming

com.example.actions#/#conventionDefault

Annotation reference

The Convention plugin uses a number of different annotations to override the default conventions that are used to map actions to URLs and locate results. In addition, you can modify the parent XWork package that actions are configured with.

Action annotation

The Convention plugin allows action classes to change the URL that they are mapped to using the Action annotation. This annotation can also be used inside the Actions annotation
to allow multiple URLs to map to a single action class. This annotation must be defined on action methods like this:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.convention.annotation.Action;

public class HelloWorld extends ActionSupport {
  @Action("/different/url")
  public String execute() {
    return SUCCESS;
  }
}

Our action class will now map to the URL /different/url rather than /hello-world. If no @Result (see next section) is specified, then the namespace of the action will
be used as the path to the result, on our last example it would be /WEB-INF/content/different/url.jsp.

A single method within an action class can also map to multiple URLs using the Actions annotation like this:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.convention.annotation.Action;
import org.apache.struts2.convention.annotation.Actions;

public class HelloWorld extends ActionSupport {
  @Actions({
    @Action("/different/url"),
    @Action("/another/url")
  })
  public String execute() {
    return SUCCESS;
  }
}

Another usage of the Action or Actions annotation is to define multiple action methods within a single action class, each of which respond to a different URL. Here is an example
of multiple action methods:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.convention.annotation.Action;
import org.apache.struts2.convention.annotation.Actions;

public class HelloWorld extends ActionSupport {
  @Action("/different/url")
  public String execute() {
    return SUCCESS;


  }

  @Action("url")
  public String doSomething() {
    return SUCCESS;
  }
}

The previous example defines a second URL that is not fully qualified. This means that the namespace for the URL is determined using the Java package name rather than the Action annotation.

Interceptor and interceptor stacks can be specified using the interceptorRefs attribute. The following example applies the validation interceptor and the defaultStack interceptor
stack to the action:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.convention.annotation.Action;
import org.apache.struts2.convention.annotation.Actions;

public class HelloWorld extends ActionSupport {
  @Action(interceptorRefs={@InterceptorRef("validation"), @InterceptorRef("defaultStack")})
  public String execute() {
    return SUCCESS;
  }

  @Action("url")
  public String doSomething() {
    return SUCCESS;
  }
}

Parameters can be passed to results using the params attribute. The value of this attribute is a string array with an even number of elements in the form {"key0", "value0, "key1", "value1" ... "keyN", "valueN"}. For
example:

com.example.actions.HelloWorld

package com.example.actions;

import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.convention.annotation.Action;
import org.apache.struts2.convention.annotation.Actions;

public class HelloWorld extends ActionSupport {
  @Action(interceptorRefs=@InterceptorRef(value="validation",params={"programmatic", "false", "declarative", "true}))
  public String execute() {
    return SUCCESS;
  }

  @Action("url")
  public String doSomething() {
    return SUCCESS;
  }
}

If interceptors are not specified, the default stack is applied.

You can specify className parameter which can be especially useful when Spring Framework is used to instantiate actions.

Applying @Action and @Actions at the class level

There are circumstances when this is desired, like when using Dynamic Method Invocation. If an execute method
is defined in the class, then it will be used for the action mapping, otherwise the method to be used will be determined when a request is made (by Dynamic Method Invocation for example)

【上篇】iOS开源框架
【下篇】原创 -128的二进制有原码反码和补码

作者: yushegen

该日志由 yushegen 于11年前发表在综合分类下，最后更新于 2013年06月30日.
转载请注明: Convention Plugin | 学步园 +复制链接

抱歉!评论已关闭.

学步园