HDIV and Spring MVC integration [SPR-7943]

[spring-projects-issues]

Roberto Velasco opened SPR-7943 and commented

Nowadays there is an intregration between Spring MVC and HDIV that can be used by adding the HDIV filter and by using Spring MVC's custom tag extension. This means that it is possible to apply HDIV to a web
application developed in Spring MVC in a declarative way, without making any change to the source code.

But this approach has a maintenability disadvantage that forces to release a new set of HDIV custom tags for every new version of Spring MVC. This does not happen to the HDIV core and web filter, as they are
no intrusive extensions.

This problem arises because there isn't a clear extension point of the Spring MVC´s custom tags that will make possible a clear extension of the component's behaviour without having to create a new version of it.

Consecuently, it is necessary to create a new version of HDIV's custom tags for Spring MVC each time a new version of the framework is released.

Also there is the risk that the behaviour of the Spring MVC's custom tags may change in the future and become not compatible with HDIV.

The objective of this new feature is to have an official integration between HDIV and Spring MVC that eliminates the maintenance cost that exists today for new versions of Spring MVC. This integration will provide an integrated and compatible solution even for future versions of both frameworks.

In order to get this purpose, we propose the creation of a Java interface or contract that will be used by Spring MVC's custom tags. With this extension point it will no longer be necessary to create specific Spring MVC custom tags for HDIV, reducing the integration task to only implementing the interface.

I have attached an interface proposal (ParameterProcessing).

Spring MVC tags should use this new interface in order to avoid tags extension. I have attached two examples of Spring MVC tags (FormTag, HiddenTag) using this new interface.

HDIV needs to process al urls sent to the client and needs to intercept redirects. Currently we extend Spring MVC default viewResolver. Spring MVC ViewResolver should use the new interface in order to avoid the extension.

This Java interface for Spring MVC tags could be used for other objectives besides integrating with HDIV. For example it could be used for integrating Webflow with Spring MVC.

Webflow needs to add an extra parameter (flowexecutionkey) for possible requests created in a web application (links and forms) in order to indicate the active flow. Thanks to this new interface this parameter could be added in a trasparent and automatic way for programmers.

In fact, this functionality is included nowadays in the HDIV version for Spring MVC.

---

Affects: 3.0.6

Attachments:

• FormTag.java (14.42 kB)
• HiddenInputTag.java (1.35 kB)
• mvc-showcase-spr-7943.zip (474.38 kB)
• ParameterProcessing.java (3.10 kB)
• spring-webmvc-spr-7943.zip (40.07 kB)

7 votes, 8 watchers

[spring-projects-issues]

Gorka Vicente commented

First, remark that we have changed the name of the interface used for the integration between Spring MVC and HDIV, calling ParameterHandler. We have also modified the definition of the interface adding the request in each method and deleting init method in order to have an stateless implementation.

Then, we are going to discuss the place where the interface is initialized and the places where it is used.

1. ParameterHandler initialization: we have changed the servlet initialization (DispatcherServlet) adding a new strategy: ParameterHandler. Like other components of the architecture of Spring MVC (LocaleResolver, ThemeResolver, etc.), if not set any bean with name "parameterHandler" will use the default instance (DefaultParameterHandler) that is defined in the file DispatcherServlet.properties. This implementation does nothing and only prints the parameters are processed during the view rendering process.

To use HDIV, we must define the following bean, in order to overwrite the default implementation:

<beans:bean id="parameterHandler" class="org.hdiv.web.servlet.tags.HDIVParameterHandler" />

2. Using ParameterHandler: as we mentioned, this interface is used in the tags to get an intercept point in the parameters of the requests.

We have implemented the method getParameterHandler in RequestContextUtils class, obtaining the ParameterHandler instance added to the request in the servlet DispatcherServlet. Thus, from any tag can be accessed easily parameterHandler instance.

We have implemented only 3 tags (FormTag, HiddenInputTag and UrlTag) in this approach. As an example, the implementation of HiddenInputTag tag would be:

	@Override
	protected int writeTagContent(TagWriter tagWriter) throws JspException {
		tagWriter.startTag("input");
		writeDefaultAttributes(tagWriter);
		tagWriter.writeAttribute("type", "hidden");

		String displayValue = getDisplayString(getBoundValue(), getPropertyEditor());
		String displayName = getDisplayString(evaluate("name", getName()));			
		HttpServletRequest request = (HttpServletRequest) pageContext.getRequest();
		ParameterHandler parameterHandler = RequestContextUtils.getParameterHandler(request);		
		parameterHandler.processFormParameterName(request, displayName, "hidden");
		String processedValue = parameterHandler.processFormParameterValue(request, displayName, displayValue, "hidden");
		
		tagWriter.writeAttribute("value", processedValue);
		tagWriter.endTag();
	
		return SKIP_BODY;
	}

3. Web application sample: we have made changes to the application mvc-showcase-1.0.0 to make use of the new library "spring-webmvc-spr-7943", which contains the changes discussed for a clean and maintainable integration between HDIV and Spring. This application uses the default implementation of ParameterHandler (DefaultParameterHandler), printing, so every time you go to render a form, a hidden field or a url (implemented by the tag spring:url), information of the parameter or url in the rendering process.

As you can see, this is only a first approximation because only 3 tags use of the new interface but, although the first approach, we believe that the initialization and the way tags consume parameterHandler instance is the most correct.

In order to develop the other tags, view resolvers, etc. where parameterHandler will use, we expect your reply to know if the proposed intercept point convinces you or not.

[spring-projects-issues]

Rossen Stoyanchev commented

A RequestDataValueProcessor interface is now available with methods similar to the ones in the attached code. An instance of this interface can be declared in the DispatcherServlet ApplicationContext and is discovered by name from RequestContext, the expected name is "requestDataValueProcessor".

[spring-projects-issues]

ulaganathan commented

Hi,
I have tried to integrate the HDIV with Spring MVC,it is working fine in Apache Tomcat,however it is not working in weblogic. Can anyone let me know whether the hdiv + spring mvc work in weblogic?

[spring-projects-issues]

Roberto Velasco commented

Hi,

Probably HDIV's Filter is intercepting internal forwards in Weblogic. Since Servlet 2.5 you can use <dispatcher> tag within web.xml in order to don't intercept internal forwards.