Empleo actual

As explained in the previous section, the View element of the MVC is just an interface and not the actual implemented view. By separating the view technology from the MVC components in the web layer, we have introduced a thin layer on top of the web logic. This layer represents the view implementation. By providing a View interface, Spring has

introduced another hinge for us to adapt the Spring MVC to our specific implementation. By using this interface and separating the view implementation, we have enabled other

developers to change the views to their specific needs. For instance, if Joly needed to produce statistical reports, a view technology accommodating this could easily be integrated.

We have implemented the views using JSPs with JSTL and Spring offers JSP/JSTL rendering “out of the box”, so we can use Spring MVC’s InternalResourceViewResolver that supports the appropriate JstlView subclass.

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass"> <value>org.springframework.web.servlet.view.JstlView</value> </property> <property name="prefix"><value>/WEB-INF/jsp/</value></property> <property name="suffix"><value>.jsp</value></property> </bean>

Figure 7.4.5 Bean configuration of Spring MVC’s InternalResourceViewResolver.

We have configured the ViewResolver to concatenate all view names with the prefix “/WEB- INF/jsp/”, indicating the directory where the jsp-files are located on the server, and the suffix “.jsp”, indicating that it is a jsp-file. By doing this, neither the placement of the view files, nor the actual type of view technology used, needs be hardcoded in our controllers. If the view technology is to be replaced, we can still use the same controllers and models, and simply alter the configuration of the ViewResolver.

In addition to configure the ViewResolver to recognize logical view names and associate them with the physical view file, we have configured the ViewResolver to render these files with a JstlView. This is the alternative to write our own implementation of the View

interface. We chose to use an available implementation in the framework to render our jsp- files because Spring offered a very suitable implementation.

In the following sections we will describe how we have resolved a couple important aspects related to the views of Joly, and how the used features can also enhance the views of the DHIS application.

Validation of user input

Validation is an important aspect of web application development. Almost all web

applications with a browser user interface will need to validate the user input. The support for validation is one of the features a good web frameworks should entail and can often be a deciding factor when choosing web framework. Validating the Spring way offers a fairly simple validation system, if the Commons Validator framework is not used, as is the case of the Joly implementation.

When data is bound to an object, it can be subject to domain object validation. Each domain object that needs validation, because it is used directly in the views, has a validation class associated with it. This class inherits the Spring Validate interface. Spring MVC takes care of calling the validation objects when a view that has data bound to an object, is submitted. To glue the domain object, its validation object, the view and the controller together, we use the Spring IoC container and extend this into the web layer. This is an example of how easily Spring MVC can collaborate with the domain layer using an IoC container. A visualization of how the components are configured is provided in figure 7.4.6.

<bean id="AddAssignmentController"

class="uio.ifi.joly.web.AddAssignmentController"> <property name="formView"

value="jolyadmin/AddAssignment" /> <property name="validator">

<ref bean="assignmentValidator" /> </property>

</bean>

Joly-serlvet.xml

<spring:bind path=Assignment.assignmentNo>

<input type=”text” name=”${expression.value}” /> </spring:bind>

AddAssignment.jsp

<bean id="assignmentValidator"

class="uio.ifi.joly.domain.logic.AssignmentValidator" />

applicationContext.xml

public class AssignmentValidator implements Validator{ public boolean supports(Class givenClass) { return givenClass.equals(Assignment.class);

}

public void validate(Object obj, Errors errors) { Assignment as = (Assignment) obj; if (as == null)

errors.reject("errors.nullpointer", "No data received"); else{

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "assignmentNo",

"empty.assignmentNo", "field cannot be empty");

if(new Short(as.getAssignmentNo()) != null)

if(as.getAssignmentNo() <= 0){

errors.rejectValue("assignmentNo", "error.assignmentNo",

"invalid assignment number"); }

…

AssignmentValidator

Figure 7.4.6 Binding and validating the Spring way. Joly-servlet.xml is the Web Application Context where all the beans of the web layer are configured. The web context can reference beans in the application context. The validators are configured in the application context because they are associated

with domain objects.

An example scenario where validation needs to be performed, is when an employee wants to register a new assignment and supplies the required information in the fields of an html form. The data entered is going to be used to set the properties of an Assignment object, which will be persisted in the database. Some data need to be saved as numbers, such as the assignment number, so when the request is received by the server, the html string containing the data, needs to be checked to see if the employee has entered a valid number. If not, the employee will be prompted with an error message and be able to correct the wrongly entered data.

For advanced validation requirements, which is more likely to appear in the DHIS project than in Joly, the well-known Commons Validation framework can be integrated with Spring and handled from the container. In stead of incorporating the Commons Validation

framework one selves, it is possible to let the Spring framework take care of the dependency. This is an example of how Spring has integrated another framework to reuse existing

expertise. The Commons framework introduces a plugin architecture of validation rules that can be used to adapt the application to user-specific validation rules. DHIS, as described in chapter 2.5, requires a customization of validation rules for each user, and thus the Commons Validation can be used to support these requirements.

Internationalization

One of the aspects of the view implementation, has been to internationalize the views with text messages of the local language. This has been important mainly because DHIS has a requirement of being multilingual, but also because we see the need of the Joly application to support foreign students. The views contain a lot of text that needs to be translated into the different supported languages. Without the support of a tool handling the localization of the views, we would have to multiply each JSP file with the number of supported languages and translate the text to be displayed in each. By using Spring’s support for message sources and combining it with the i18n-capable formatting library of JSTL, we have enabled the views to easily be internationalized.

<bean id="messageSource"

class="org.springframework.context.support.ResourceBundleMessageSource">

<property name="basenames">

<list>

<value>etc/ViewMessages</value>

</list>

</property>

</bean>

Joly-servlet.xml

Figure 7.4.7 Configuration of a Spring implemented message source.

A Spring message source is configured with the localization of a properties file. This enables JSPs to access the properties by using JSTL tags.

label.assignment=Oblignr.

button.insert=Legg inn

error.assignmentNo=Feil i angitt oblignr.

typeMismatch.java.lang.Short=Feil format på inntasted data. Vennligst angi et tall.

<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

…

<label for="assignmentNo"><fmt:message key="label.assignment" />: </label> <input type="submit" value="<fmt:message key="button.insert" />" /> …

ViewMessages.properties

AddAssignment.jsp

Figure 7.4.8 Excerpt of the ViewMessages and AddAssignment files showing the use of JSTL fmt tag library and Spring’s message source.

7.5 Summary

When presenting the implementation of the Joly application, our focus has been to describe how we have implemented the design laid out in chapter 6 and how we have used the selected tools to provide both functional and non-functional support. Because of the focus on

implementing the application to conform to the design patterns chosen, we have discussed the design decisions and revisited some of the previous discussions in this chapter as well. It may seem like we have spread the general design discussion to all chapters covering the Joly application, but we have felt the need to explain the general design when discussing how the detailed implementations conform to and support the overall design of the application.

The implementation of the specific functions of Joly shows how to use the frameworks and the concepts they are built on. This chapter has therefore described how to resolve the functional requirements as well as the non-functional requirements of the application. The level of detail has been high in some areas, but we felt that this was necessary to show how frameworks can be used to solve specific tasks and how to customize the general classes of a framework to ones own implementation.

We have described how we have implemented the persistence layer so that it is flexible towards database substitution. The integration of Hibernate is done in a manner that makes

Hibernate easily removable by using annotations as opposed to xml-mappings. The chosen release of Hibernate also enables the application to support implementation of EJB3 in the future.

The domain layer is implemented so that components can easily be substituted and added. In addition, the domain logic is accessible to all type of layers, such as web service layers, to support a potential requirement of web service implementation.

The web implementation conforms to today’s standard when implementing web logic, by applying the web MVC pattern and implementing classes with the assigned responsibilities. The implementation and use of Spring’s MVC framework has enabled the application to adapt to different types of view implementation, making the application flexible to developers’ choice of technology in the presentation layer.

Chapter

8

Experiences

In this chapter we will present the experiences we have gained from the investigation process and development of the Joly application. We will point out the problems we have encountered when using free and open source tools and other relevant experience gained from the

development process.

8.1 Experience gained by the analysis process of the DHIS