Part of the API of RSF is defined traditionally, in terms of public methods and interfaces. However, RSF also exposes what could be called a Spring API - that is, a set of named beans (of types determined by RSF interfaces) that application developers may (or sometimes must) define in their Spring configuration files.

Spring Framework is a marvellous framework whose purpose is to manage the transport of dependencies from one part of an application to another. This capability is sometimes also called "Inversion of Control". Instead of being manually copied around from object to object, your dependencies are declared in a static configuration file, in Spring, called an application context file. At context startup time, these dependencies will be autowired based on a topological sorting of the bean graph defined in the configuration file.

RSF is organised from a set of several such files, some specifying beans with application lifetimes, others with request scope lifetimes. The location of these files are configured in context parameters in the application's web.xml file - apart from the standard RSF core files, an application may define an arbitrary number of such files in arbitrary locations. However, the default RSF configuration gives some standard names to these files.

Scope	RSF Core	"Blank" Definitions	Default Application File
Application Scope	classpath:conf/rsf-config.xml	classpath:conf/blank-applicationContext.xml	/WEB-INF/applicationContext.xml
Request Scope	classpath:conf/rsf-requestscope-config.xml	classpath:conf/blank-requestContext.xml	/WEB-INF/requestContext.xml

These configuration files are defined inside the JARs defining the RSF framework - in general, an RSF "module" (such as RSFHibernate, or SakaiRSF will also be packaged as a self-contained Spring-configured library of this sort, and will add to the list of files to mention in web.xml.

An application will in general define at least one view, for example:

<!-- Define the component producer for the main view -->
  <bean id="main-view" class="uk.org.ponder.rsf.helloapp.components.MainProducer"/>

and also a list of requestAddressibleBeans. In general, in addition to defining beans for its own use, it may configure RSF by overriding some of the definitions from one of the "blank" configuration files (or even in extreme cases some of the core beans). Context files listed later in the web.xml file will simply override beans of the same name which appear in files listed earlier. For this reason the RSF context files should always be listed earlier than application definitions, as in the following extract from a "typical" web.xml file:

<!-- Configure standard Spring application contexts. Be sure to mention
    rsf config files first, so any overrides may be processed -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:conf/rsf-config.xml,
                 classpath:conf/rsf-blank-applicationContext.xml,
                 /WEB-INF/applicationContext.xml,
                 /WEB-INF/userconfig.xml
    </param-value>
  </context-param>

Definition of RSF Spring API#

The following table will list all the beans constituting the Spring API of RSF (currently extremely incomplete):

Bean	Scope	Interface/Base Class	Purpose
templateResolverStrategy	Application	uk.org.ponder.rsf.templateresolver.SimpleTemplateResolverStrategy	Defines the rules used to look up the view template to be used for rendering the current request. RSF defines a very simple TemplateResolverStrategy called CRITemplateResolverStrategy that just uses the view ID and consumer ID to locate a single template file in a named directory.
actionResultInterpreter	Application	uk.org.ponder.rsf.flow.ActionResultInterpreter	Implements the "flow" of the application, defined by the state transitions to different views occuring after successful and unsuccessful POST requests.
requestWriteableBeans	Application	uk.org.ponder.stringutil.StringList	A list of the names of the "root beans" in the request scope container that are considered addressible by EL incoming through the request. This makes the request submission process more secure, in preventing the execution of arbitrary EL. Note that no further checks are made on derived properties of the root beans, of which writeability is determined solely by the model.
copyPreservingBeans	Application	uk.org.ponder.stringutil.StringList	A list of EL paths whose values will be preserved by simple Object reference copying between requests participating in an RSF flow (whilst using the default definitions for statePreservationStrategies and related beans held in blank-requestContext.xml)

(Many more to follow - consult blank-applicationContext.xml and blank-requestContext.xml)

In a framework organised entirely around Spring, as RSF is, this creates an unprecedented level of fine-grained control over the structure of the application. Since Spring allows "bean overrides", any RSF component, not just the mandatory application components listed above, may be replaced by listing it in the application's configuration files.

---

You can post comments and questions on this page using the following blog. Please set your name using UserPreferences before posting. New entry