Spring framework support in HST-2

(This article was migrated from http://blogs.onehippo.org/woonsan/2009/04/spring_framework_support_in_hs_1.html, originally written on April 20, 2009.)

I'd like to explain the current status to support Spring Framework-based developer community.
HST-2 (Hippo Site Toolkit - 2) now supports Spring Framework more than the earlier versions because there are a lot of developers utilizing the framework.

1. Introduction

It is very desirable to use spring web framework if the development team is familiar with Spring and they could make better productivity with that.
HST-2 now provides a bridge HstComponent to HstComponent beans which are managed by spring web application context.
So, you can define your HstComponent beans in your spring context configuration and inject your existing component to them. You can see an example in the HST-2 source already if you download the source from the trunk for now.
In the Hippo Test Suite project, 'contact-spring' menu will show the example which uses the bridge component. The actual bean is defined in /WEB-INF/applicationContext.xml like the following:

  <!-- HST Component Beans -->
  <bean id="contactBean" class="org.hippoecm.hst.components.ContactSpring">
    <property name="mailSender" ref="mailSender" />
    <property name="templateMessage" ref="templateMessage" />
  </bean>

  <!-- The existing components as an example -->
  <bean id="templateMessage" class="org.springframework.mail.SimpleMailMessage">
    <property name="to" value="contact@mycompany.com" >
    <property name="subject" value="My opinion" >
  </bean>

  <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
    <property name="host" value="mail.mycompany.com"/>
  </bean><br>

2. How it integrates with HST 2.3?

HST container manages, invokes and aggregates only components based on HstComponent interface for some reasons: to support transparent page aggregation, seamless portal integration, etc.
A generic HstComponent was developed to play a role as a bridge to a bean managed by spring framework.
So, the generic bridge HstComponent will delegate all invocation to the actual HstComponent bean managed by spring framework.

3. What the benefits are? What the drawbacks are?

Spring-based developers can use full cool functionalities of spring framework like Dependency Injection, out-of-box spring components to support enterprise computing like JDBC template, transaction management and enterprise messaging, AOP techniques, Web Service support, Various view technologies, etc. HstComponent can be fully integrated with these rich spring supports.
The Spring Bridge HstComponent invokes directly the actual bean, so there's no performance degrade and functional shortage here. 
Of course, it looks a little bit different from the original spring web mvc pattern. The differences you can think of are originally from the differences of goals: HST-2 is to support transparent page aggregation and seamless portal integration, etc. Because HST-2 container aggregates multiple components in one page, the action phase should be separated from the rendering phase of all components. This means that HST container's aggregation should imply the PRG pattern internally. [1] Therefore, in a HST component, the *controlling* logic should be separated in doAction() and in doBeforeRender(). Also, those two separate phase should have separate request life cycles. 
Anyway, once you get accustomed to HstComponent request lifecycles, you can easily use the pattern with HstComponent in the spring framework best practices. For example, spring developers can write controller logics in HstComponents and use any kinds of view technologies to build view pages. 
On the other hand, somebody can ask me, 'why can't spring webmvc manage the request handling directly itself? why HST container controls the request at the frontend and it dispatches to spring web mvc later?'  The answers can be like the following:

• HST manages the page aggregation like portal. If you want to use that kind of page aggregation and you don't want to care its detail except of focusing on making each component block, you need to hand it over to HST container. HST container promises that it would provide transparent page aggregation, sitemap/sitemenu and seamless portal integration. 
• If you don't want that kind of page aggregation, you can still use some HST components as out-of-box components such as JCR session pooling repository, event listener (observation), search helper, etc. by definining those components in your spring configuration.

4. What's next?

I think this spring bean bridging solution is very useful for many use cases. However, some Spring Web MVC framework-proficient developers can complain that they cannot use some kind of handler mappings for each controller.
I agree that this simple bridging solution could not be enough for the developers.
I think we can go further by providing *HST component phase parameter handler mapping*. :-) This can be regarded as *HST Spring Web MVC*.
Sounds like org.springframework.web.portlet.handler.PortletModeParameterHandlerMapping of Spring Portlet Web MVC?
Yes, because the request life cycle of HST component is very similar to portlet, almost similar design can be adopted.
However, I think there are some better features in HST Spring Web MVC than Spring Portlet Web MVC. One is the fact that Hst Component controller in HST Spring Web MVC might not be tied to portlet api directly.
Anyway, I'd like to look into this improvement soon. Please stay tuned!