Essentials
Get Involved
Documentation
Howto Guides
Development
|
RunData Service
|
|
RunData is an interface that is passed around within Turbine. RunData
provides the threading mechanism, as there is one RunData object per
HTTP request. The RunData service manages the isues surrounding multiple
requests being accepted. TurbineRunData is the interface that is
specific to the Turbine RunData service, and via the recyclable
interface can be sent back to the Factory for recycling.
RunData objects should never be held on to across requests. They are
considered one time only objects.
All this higher level processing by the service means that for each HTTP
request there is an interface that is castable to, or available, that
can be used to access all information to do with that request. As an
example, information such as the content type of the request and the
response can be queried or sent, as well as other information
surrounding servlet HTTP management, such as Sessions, PrintWriters as
well as Turbine specific information such as Users, AccessControlLists,
Templating, Error Handling and Contexts.
|
|
Using RunData
|
|
As RunData encapsulates all aspects of Turbine's gathering the
HttpRequest and sending the HttpResponse, any status to do with the
Request can be queried and any manipulation of the final response can be
carried out through the RunData Object.
Turbine is a servlet and the functionality equated with the
javax.servlet and javax.servlet.http can be manipulated through the
RunData interface. One of the most useful components of the Servlet
libraries was Sessions. These are accessed through RunData; it also
provides direct access to the PrintWriter, Server details, Content
Types, ContextPath, Redirections, Client details, etc. Some of the
functions which equate with the servlet libraries are:
 |
 |
 |
 |
getLocale()
setLocale(Locale locale)
getCharSet()
setCharSet(String charset)
getContentType()
setContentType(String mimetype)
getOut() //get PrintWriter Object
getRedirectURI()
getRemoteAddr()
getRemoteHost()
getRequest()
getResponse()
getServletContext()
getSession()
getStatusCode()
|
 |
 |
 |
 |
The get/setLocale(), get/setCharSet() and get/setContentType() methods
are used for specifying the locale, character encoding and content type
of the body of the servlet response.
The method setLocale() is called to specify explicitly the locale
of the response. If setLocale() is not called, the "locale.default.language"
and "locale.default.country" properties from Turbine Resources are used to
determine the locale. If these properties are not set, the JVM's default
locale determines the locale.
If the locale is set to something else than the default locale or Locale.US,
an explicit encoding is not specified with the setCharSet() method or the
"locale.default.charset" property, and the main MIME type of the content is
"text", the getContentType() method adds a locale specific encoding (charset)
to the content type automatically.
The locale specific charset is obtained from the MimeTypeService, which
maintains mappings between locales and charsets.
As always consult the Javadocs for more detail.
To use Turbine to only manipulate the functions that came with the Sun
Servlet libraries is to miss out on Turbine's power. Turbine is a
framework which enables manipulation of the HttpResponse and HttpRequest
above and beyond the simple Servlet libraries. Turbine has services and
layers surrounding those available with the Response and Request that
allow easier creation and management of Websites and Web-enabled
Applications. In fact you wont have to type import javax.servlet.*
again!
|
|
Session Management
|
|
Sessions are managed in Turbine via the User interface. The User
interface allows for a blend of cookie management, memory management and
relational database to be used to manage a user's session. A user of the
site can have their Turbine session set as either temporary storage or
permanent storage. The permanent storage will survive a servlet engine
restart. How all this is managed by Turbine is transparent to the Java
Engineer. As an example assume we want to monitor how often a user
returns to the website we are developing and we want to reward them for
their returning interaction:
 |
 |
 |
 |
//in Login Action class
public void doPerform(RunData data, Context context)
throws Exception
{
//get the Parameters, username and password
ParameterParser params = data.getParameters();
String loginname = params.getString("username");
String password = params.getString("password");
try
{
//cast to TurbineUser interface
//and check if user is in system
TurbineUser user = (TurbineUser)
TurbineSecurity
.getAuthenticatedUser(loginname, password);
//put User into Session
data.setUser(user);
//mark the User as logged in
user.setHasLoggedIn(new Boolean(true));
//add to the access counter
user.incrementAccessCounter();
//add to the access counter for the session
user.incrementAccessCounterForSession();
//check to see if user is to have
//their status changed to valued
if(user.getAccessCounter() > 500 )
{
//set into persistant storage
//that our visitor is now a
//valued user
user.setPerm("valued", new Boolean(true));
}
data.save();
}
catch (Exception e)
{
//error handling
}
}
|
 |
 |
 |
 |
While skeletal this shows a good example of permanent and temporary
management of User information. The line data.setUser() puts the User
into session, the hasLoggedIn() method updates the User Object to
reflect the fact that the session has passed Authentication; however
until the RunData's save method is called both the User and hasLoggedIn
flag are only existing in Turbine's memory. Neither become a part of
RunData's HttpSession until they are saved into the session through
data.save(). The AccessCounter is persistent storage and is saved into
the database. The AccessCounter for the session counts the number of
pages that are requested throgh Turbine for the user's session. Once
their session logs out or the session times out, that information is
lost. The user.setPerm() method allows for information to be stored
persistently into the database as a HashTable entry. The example above
was intended to show that information can be handled through a
consistent interface allowing for the management at the
request/response, session and persistent levels without any direct
manipulation of the HttpRequest, HttpResponse, HttpSession or Relational
database. As always, refer to the Javadocs for more information on the
RunData, User and TurbineUser interfaces.
|
|
|