Skip to main content

Posts

Showing posts from September, 2012

Part 3 - Introducing Spring Security, Thymeleaf and Spring MVC

Security is one of the key aspect of an application, especially web application. In our application we intend to integrate Spring Security as we are already on Spring framework. Alternative was Apache Shiro. But we prefer Spring Security. Here is how we can integrate Spring Security with Spring MVC and Thymeleaf. The first step to this integration is to include the Spring Security and Thymeleaf Spring Security jars into our application. This can be done by adding Maven dependencies. Here is the snippet from the parent/pom.xml file. Listing 1 - parent/pom.xml - snippet <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- SPRING SECURITY --> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-config</artifactId> <version>${spring-security.version}</version> </dependency>

Part 3 - Integrating Tiles, Thymeleaf and Spring MVC 3

In this post I will demonstrate how to integrate Apache Tiles with Thymeleaf. This is very simple. The first step is to include the tiles and thymeleaf-tiles extension dependencies. I will include them in the pom.xml. Note we wil lbe using Tiles 2.2.2 Listing 1 - parent/pom.xml --- thymeleaf-tiles and tiles dependencies <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- Tiles --> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <dependency> <groupId>org.apache.tiles</groupId> <artifactId>tiles-core</artifactId> <version>${tiles.version}</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.apache.tiles</groupId> <artifactId>tiles-template</artifactId> <version>${tiles.version}</version> <scope>compile</s

Part 3 - Validation

In this episode, I will show in easy steps how to integrate Hibernate Validator - the reference implementation of JSR 303 - Bean Validation into our application. Hibernate Validator is already part of our application thanks to the inclusion of the relevant jar in the parent pom file. Let us add a simple validation into our domain object - Lead - let us not allow a blank for the first name. The modified Lead class is shown in Listing 1. Listing 1 - Lead.java package com.effectivcrm.domain; import javax.persistence.Column; import javax.persistence.Embedded; import javax.persistence.Entity; import javax.persistence.Table; import lombok.Getter; import lombok.Setter; import org.hibernate.envers.Audited; import org.hibernate.validator.constraints.NotEmpty; /** * The persistent class for the leads database table. * */ @Entity @Table(name = "t_lead") @Audited public class Lead extends PersistentObject { private static final long serialVersionUID = 1L; @Getter @Setter @

Part 3 - Introducing the domain objects and first lead create view

As I decided that I will go with static forms instead of dynamic ones, I set sail creating the createlead.html page with Thymeleaf support and Spring MVC.The listing below shows the form: Listing 1 - createlead.html <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:th="http://www.thymeleaf.org"> <head th:include="common :: headerFragment"> <title>effectiv:Home</title> </head> <body> <div class="navbar navbar-inverse navbar-fixed-top"> <div class="navbar-inner"> <div class="container-fluid"> <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span>

Part 3 - Introducing Project Lombok and thinking the dynamic form model

We are at the verge of writing few beans and I personally hate those getter/setters toString hashCode, equals to be written for each one of them.I am also not too confident or knowleagble about tools like Spring ROO. So what option I have to save myself from these boring boilerplate clode. I can save some by using Project Lombok. Project lombok is available at - http://projectlombok.org/. I will not show here how to integrate it with STS, its straight forward and well documented on the product website.Do not forget to include it as a maven dependency in the parent project to use it in child projects and save some time. Dynamic form Creating the dynamic form will be an excellent thing. We have lot of meta data to do that in the domain objects. We can even keep the form meta information in xml or database. The Spring Thymeleaf dialect already has excellent support for forms. For the moment we will put the dynamic form into parking lot and build forms using Thymeleaf. In future if this re

Part 3 - Enhancing the view layer - Creating the screen prototypes & dyna form

We now have a more or less stable version 0.0.2. You can find it in tagged version 0.0.2 on SVN. Now I will try to create the prototypes for our views. We can do that creating new Thymeleaf templates. One big advantage of Thymeleaf is that it supports natural templating so you can view it easily on the browser offline i.e without running it on Tomcat. Unfortunately we have already lost that advantage as our css,images, and js are packed in jar. But it should not be a big deterrent to our prototyping effort. Its a lightweight application and we can run it on Tomcat and view the changes quickly. I will also sacrifice the natural templating feature of Thymeleaf for another reason. I want flexible forms driven by meta data --- Hibernate annotations of the domain objects or may be database driven forms. Hence I will extend Thymeleaf to support additional dialects to create a new tag -- "datatable". Also this form will be driven by custom actions / buttons all configurable. The new

Part 2 - Enhancing the setup

As you can seen modularity has a price. Our application will be divided into multiple Maven projects / modules. Lets say in development I change 2-3 modules, then I need to build each one of them to test. This can be irritating and time wasting. Also I am a lazy developer, I will want to build them as one go. Hence I will now create a multi-module Maven build parent - child. I will just build the parent to build all my childs, including the aggregator ecrm project, which we will essentially deploy. So we create a maven quick start archetype project. You can turn this into parent project as shown in Listing 1. Also I will refactor the pom in ercm project by moving dependencies and properties to the parent. Similarly view/pom.xml is modified to treat it as a child project. Listing 1 - parent/pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0