See: Description
| Package | Description |
|---|---|
| org.dihedron.strutlets.containers.web.tomcat | |
| org.dihedron.strutlets.containers.web.tomcat7x |
The Strutlets project is an attempt to create a simple framework to ease the development of JSR-286 compliant portlets. It is deeply inspired by the elegant MVC implementation provided by Struts2, from which it borrows part of its name (Struts2 + Portlets yields Strutlets).
The Strutlets library implements the MVC pattern the Struts2 way: it provides a single controller portlet that receives all incoming requests and translates them into action method invocations; once the action's method has completed, the framework regains control and based on the action result and on an XML configuration file, on annotations or on educated guesses it dispatches the call to the appropriate render engine, whether a JSP or some other rendering mechanism (e.g. one producing JSON or XML output).
In addition to this basic logic, the framework provides multiple extension points, e.g. by emulating the interceptors logic of its senior brother. The invocation process flows through a stack of interceptors before reaching the action method, and each of these (pluggable) interceptors can massage the request and response objects, manipulating parameters, results and the action itself, and adding value to the processing. Interceptors are the ideal place to plug in any additional aspects, such as reporting, auditing, profiling, dependency injection and the like; all of this can be implemented in a fully reusable way.
Before creating any portlet, the strutlets JAR and a few other libraries must be imported; when using strutlets through Maven this configuration step can be automatically done for you by Maven itself, by simply adding this fragment to your POM:
<dependency>
<groupId>org.dihedron.strutlets</groupId>
<artifactId>strutlets</artifactId>
<version>0.4.0</version>
</dependency>
Otherwise, you need to add the following JARs to your WEB-INF/lib directory:
The framework relies on a single portlet to dispatch control to actions and then to views as necessary. Each portlet in your project will need to have its own instance of the portlet, with its own configuration, its own Actions and Views.
In order to set up the Action Controller, you need to declare it in the portlet.xml and in any additional configuration files, as per your portal server documentation (e.g. liferay-portlet.xml on Liferay). The typical setup in portlet.xml is achieved by adding the following lines:
<portlet>
<portlet-name>portlet1</portlet-name>
<display-name>My First Portlet</display-name>
<portlet-class>org.dihedron.strutlets.ActionController</portlet-class>
[... configuration goes here ...]
</portlet>
For details on the configuration, see the next chapter. You can add
this same snippet multiple times: just make sure you've modified the portlet
references (name, display name, and configuration) in order to make each
instance unique.
Once you've added the other JSR-286 required parameters, the portlet is ready to be deployed even without specifying any parameter: the framework will assume the defaults are OK for you, and will self-configure accordingly.
The portlet is highly configurable. It currently supports the following parameters:
com/example/applicationX/portletY/actions/my-actions-config.xml
/jsp/portlet1/and it gets appended to the application's web
root: it will typically be a subdirectory of /docroot in your WAR file; this
parameter is used to build the path to view resources for automatically
configured Actions
${rootdir}/${action}/${method}/${result}.jsp
which will yield /jsp/portlet1/MyAction/myMethod/success.jspfor a
successful invocation of MyAction's
myMethod(); the accepted variables are shown in the example,
along with their meaning
view, edit,
help; each entry will specify the name of the initial JSP or
web page for this portlet in the given mode.
The Strutlets framework provides two ways of configuring one's Actions: the
first is via the actions-config.xml file, the second is through
annotations. Which one to choose depends on one's tastes, yet we feel that
the use of annotations caters for improved productivity and easier maintenance;
moreover it provides a way to leverage the framework's "convention over
configuration" paradigm, so that a complex Action can be registered an made
fully functional with a single empty annotation, as follows:
@Invocable public String myMethod() throws ActionException {
... do whatever you want here, then return a string
}
... and that's it!
In order to configure your Actions ye oulde way you have to provide an XML configuration file. Normally, this file would be called The Strutlets framework enables developers to handler "render" requests through Actions: the render request goes to an Action method, which perfomrs some (read-only) business logic and accordin to the processing outcomes decides which view to render. This feature provides an additional degree of freedom to the application designer, which can choose to have her application perform some "initialisation" business logic. In order to do this, the oly necessary thing is a
renderURL, an opetional set of input parameters to it, and a server side read-only Action method. It is important for the method to have "read-only" semantics because the portlet container may reiterate the same render request to the portlet multiple times. A "read-only" portlet is idempotent: it can be called as many tames as one wishes and it will always return the same results. or at least it does not do anything that changes the internal application status and disrupts the possibility of furthe calls to the same method being performed and handled properly. In order to specify this "read-onlyness", the method should be annotated with the appropriate value or the same value should be specified in the
actions-config.xmlfor statically configured Actions.
Copyright © 2012-2014 Andrea Funtò. See here for terms and conditions.