views:

99

answers:

4

I'm looking for what view technology would be considered the best approach for Spring MVC 3.0 which is flexible, maintainable and allows multiple rendering technologies such as HTML, PDF etc...

We're looking to develop our next web application using Spring MVC 3.0 and have settled on Hibernate for persistence but are still trying to decide which is the most appropriate view technology.

We will require support for PDF reports but would most likely write these using iText.

Are there any maven archtypes which would setup a recommended application complete with persistence and view technology?

The spring samples use a bunch of different technologies from JSTL to Apache Tiles, we've only ever used JSP in the past since we moved to .NET in 2003 and are moving back to Java now.

A: 

How about Apache Velocity

That's the most popular template engine I know of. Would like to get more suggestions though.

Update:

Freemarker is another

Source

zengr
A: 

Below are a few.

  • Freemarker
  • Apache velocity
  • JSP (the new 2.1 alright with improvements like functions, simplified custom tags, etc.) with apache tiles

Here is a doc that talks about integration with view technologies

We are currently using Jsp 2.1 with spring webmvc 3.0x with apache tiles on google appengine and it servers our purpose quite well.

naikus
+1 for JSP - it's an awful lot better now than it was in 2003
skaffman
@skaffman Thanks, does that +1 mean one vote up? :D, if yes, its not showing here.
naikus
+2  A: 

There's really nothing wrong with using JSP, if you use the most recent version. You can certainly choose Freemarker, Velocity and other cool viewer, but if your entire team is already comfortable dealing with JSP, you need to take account of your project deadline and all the learning curves when taking on a new technology. If it makes sense, sure, it doesn't hurt to learn another new thing.

In my case, I use JSP with Sitemesh as my template. I used JSP/Strut Tiles combo for quite awhile but I find the template to be too intrusive, Sitemesh seems to be more seamless to me because it doesn't clutter my actual JSP files with some Tile specific custom tags.

limc
+1 for mentioning leveraging the team's existing JSP experience... this may be the cost factor people most often fail to consider.
Gweebz
I'm starting to consider this, I'm actually starting to think about dropping spring altogether and going back to our own controllers. It's not the best approach by any means, but it's something we know how to do. Do you think learning spring is actually all that worth while in the end?
Brett Ryan
I might add, our current knowledge was for JSP 1.2 and servlet 2.3 apps, we never really had a need to "upgrade" them. Since we're starting afresh with this one we figured we should go with the current.I'm guessing others have been in this position, interested to hear others approaches.
Brett Ryan
To answer your question about Spring, yes... learn it if you can. The biggest problem with home grown framework is you end up with tightly coupled modules, which makes your code very difficult to test. Spring makes your code very loose coupled and easy to test, especially when you are working in a team setting, you can ensure you guys are not stepping on each other feet, and that everyone of you adheres to the best practices, which enhances future knowledge transfer rather than trying to bring someone up to speed about your home grown framework.
limc
Thanks limc, will do. Was my initial reasoning, thanks.
Brett Ryan
A: 

If I were you, I would stick with jsps for now. You can mix and match your views in Spring if you decide certain flows will require something else. For example, you will need to use different view types if you plan to use any ajax style processing.

smp7d