Spice up your Spring experience
The riot-common module provides some useful add-ons for the Spring Framework. Most of them are used by the Riot project-skeleton so you might already have come across them.
Rewire your beans without restarting the server
When you build websites with Spring MVC (or any Java-based web framework) it's quite annoying that you have to reload the complete webapp every time you want to add or reconfigure a controller. Riot therefore provides a ReloadableDispatcherServlet that, as its name suggests, reloads its configuration whenever a config file is changed.
Use parameter-less URLs
The AdvancedBeanNameHandlerMapping allows you to replace URLs like /detail.html?id=42 by a parameter-less variant so that you could write /detail-42.html instead. It works exactly the same as Spring's BeanNameUrlHandlerMapping but lets you place @{...} placeholders in your bean name which indicate the matched part should be exposed as request attribute.
Define default values for your property placeholders
Spring provides two different types of configurers, the PropertyOverrideConfigurer and the PropertyPlaceholderConfigurer.
In contrast to PropertyOverrideConfigurer, this configurer allows to fill in explicit placeholders in context definitions. Therefore, the original definition cannot specify any default values for such bean properties, and the placeholder properties file is supposed to contain an entry for each defined placeholder.
Riot introduces a new configurer, that combines the advantages of both. The context definition is aware of being incomplete which this is immediately obvious to users when looking at the XML definition file. At the same time default values can be defined within the original definition:
<property name="driverClassName" value="${driver=org.hsqldb.jdbcDriver}" />
<property name="url" value="jdbc:${dbname=hsqldb:mem:riot}" />
</bean>
Mix multiple view technologies
In theory Spring allows you to chain multiple ViewResolvers. Unfortunately all UrlBasedViewResolvers attempt to resolve any view name, no matter whether the underlying resource actually exists. This means that you can't mix JSTL, FreeMarker, Velocity, XSLT and Jasper Reports as all these resolvers are URL-based.
To work around this problem, Riot provides the SuffixViewResolver class which picks a ViewResolver implementation based on a suffix found in the view name.
<property name="resolvers">
<map>
<entry key="jsp">
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
<property name="prefix" value="/WEB-INF/view/" />
</bean>
</entry>
<entry key="xsl">
<bean class="org.springframework.web.servlet.view.xslt.XsltViewResolver">
<property name="prefix" value="/WEB-INF/view/" />
</bean>
</entry>
</map>
</property>
</bean>
Facilitate translation by revealing the message codes
When you are woking with MessageSources it can be tricky to find out which message codes are used to perform the lookup. Riot's CodeRevealingMessageSource surrounds the returned message by a tag, which reveals the codes when you hover it with your mouse. Using the CSS class you can easily highlight all ocurrences of internationalized text. You can also use the MessageCodeRevelationController to toggle code revelation at runtime.
