I'm about to start in on a new Spring MVC project, and I'm examining the various options for the view. I've never been a fan of JSP, and I've run into JSP-related performance problems in the past, so I was looking through the other options. I'm hoping that somewhere somebody's taken a census of the various options (maybe it'll have to be me) and pronounced which ones are quick, or at least which options there are. Here are the choices I've thought of, ordered from obvious to bizarre:
JSP, JSTL
Velocity
FreeMarker
GSP (Groovy JSP)
ERB powered by IronRuby or some such craziness
Tea
Any suggestions, personal preferences, or other good options for the list?
StringTemplate - fast, simple and helps enforce MVC separation of concerns. Last I checked, Spring Web MVC doesn't provide a View class for it, but I was able to easily create a custom one.
While I would probably go with FreeMarker or Velocity myself, I am surprised at what you call
JSP-related performance problems
Of all these possible solutions, JSP is obviously the best-performing. After all, JSP pages are compiled to Servlet classes and executed from byte code whereas all the other technologies you mentioned are interpreted.
If you have performance problems, either optimize your JSP code or use a JSP compiler like JSPC to pre-compile your JSP pages (perhaps with maven, using the JSPC-maven-plugin).
I prefer Velocity these days. The performance is fine. I like the natural way it decouples the template and the data.
I used to use Velocity. The project stagnated a bit and had some known issues, so switched over to Freemarker. I believe (don't quote me) Freemarker came about because Velocity lost momentum. No pun intended.
Since then Velocity has become active again, at least for a while. I prefer Freemarker right now, but either of these two work well. I'd go with whichever one plugs in easier to Spring MVC.
I agree with Sean Patrick Floyd that JSP should be realy fast.
In most cases even faster then the other Template engines, even if they are cached.
If you realy run in an JSP related performance issue than I belive you should rethink the way how you use JSP.
And at least, if you have a hot spot which causes the performance issue, than you can build this (hopeflully) small pice by hand (StringBuilder).
So to wrapp this up: I belive JSP is the fasted one (except doing it by hand), but on the other hand, you must have a very special use case to run in a perfomace issue with any of the major template engienes you mentioned.
You should try MVEL. It is faster than anything i know (incl. StringTemplate), really powerful and feels like scripting in plain java.
<p>
#foreach{index : alphabetical}
#{index.description}
#end{}
</p>
or
<a href="#{ua.pageURI}">
#{org.apache.commons.lang.StringEscapeUtils.escapeHtml(ua.name)}
</a>
Related
I am writing a Spring MVC application and looking for a way to do layouts in views. The only option that i see is Apache Tiles, which i have used before and know how painful it is to maintain its configuration.
Are there any good alternatives? I looked at SiteMesh and Spring Surf both seem to be dormant.
I faced the same dilemma about a month ago. I have been a seasoned developer using apache tiles, and I wanted to try something different.
I did some research and found that Spring MVC has some integration with freemarker and sitemesh. I decided to give both a shot.
Tiles seems to have the most active community.
You can also try a pure velocity implementation.
To sum up, my project ended up reverting back to tiles. Tiles is a robust templating framework, and once you understand it's powers, I will find it hard to find a good replacement. Also, if you are already skilled in apache tiles, I find the benifits of switching frameworks (if any) do not justify the learning curve required to picking up sitemesh/freemarker
http://www.sitemesh.org/overview.html
http://freemarker.sourceforge.net/
Tiles and Sitemesh are very different in what they are designed for.
Tiles is used as a part of your application designed to use tiles.
Sitemash is designed as a filter in front of one or several already existing applications. Where you want to change the output of the applications (for example (a very easy task) replace the logo or add an extra menu option).
On the other hand I do not see why have so much xml. You have to write one xml block for each page to define which layout it needs. (If you still configure a list of files containing the tiles configurations then have a look at `org.springframework.web.servlet.view.tiles2.TilesConfigurer".)
If you want to get rid even of these files, then, perhaps, you should think more of extending tiles than using an other framework.
IMO SiteMesh and Tiles are both pretty good approaches, although newer Tiles releases add a lot of untapped power--it's more than a simple templating mechanism.
If you're finding maintenance an issue I'd consider wrapping it up in a thin layer of abstraction using either a DSL or light GUI, either can make a big difference.
You could use phpj
Its easy to use, comes with examples. You may use it for view templates or generate your html content any way you want to.
Although I've no experience with it personally, here's another alternative: https://code.google.com/p/commentit/
We are trying to find a java framework that requires the fewest changes to html/xhtml when we get it from the designer. So far to me it seems Sitebricks is the least intrusive, but it is still in alpha it seems and has been that way for a long time. Wicket seems to come in a pretty close 2nd. JSF, Stripes, and Struts requires a lot, what are we missing.
Tapestry has always had "very-native" html templates, from what I can remember - I haven't looked at the new version, but I don't expect that to have changed drastically.
You should check out Freemarker.
In fact SiteBricks default rendering engine rely on mvel. But SiteBricks can also support freemarker and others rendering engines.
Velocity is similar to Freemarker but I don't know it.
What changes exactly require Struts, Spring MVC, JSP? (not familiar with Stripes/JSF) The only required change I can think of is changing file extension from 'html' to 'jsp'. That's all.
Of course, different frameworks require different amount of configuration (which sometimes can be confusing), but that doesn't involve changing html.
Tapestry and Wicket are the least html-invasive. They both have the same idea of adding annotations into the html, but not butchering it through replacing every html element with taglibs.
Another framework that featured logic-less html templates was RIFE. I think it stopped being developed a couple years ago, though.
I recently added Struts 1.3 to my application on Tomcat. Here are my observations,
MVC. Servlet/JSP does this fine for me, where JSP is the view and servlet is the controller. I don't see any benefit to get the mapping from an XML file since our mapping is very static.
Action Form. I can see some benefits of action form but not huge.
Tags. I already uses JSTL and don't see any advantage using Struts tags.
So I am thinking about removing Struts. Anyone can think of any other benefits I might have missed?
Personally I myself prefer jsp/servlet but theoretically Struts has some advantages.
Here are some of the advantages i know of, you might have mentioned them already, but i thought it would be better if i list all of them here.
Centralized File-Based Configuration.
Struts values/mapping are represented in XML or property files. This loose coupling means that many changes can be made without modifying or recompiling Java code, and that wholesale changes can be made by editing a single file. This approach also lets Java and Web developers focus on their specific tasks (implementing business logic, presenting certain values to clients, etc.) without needing to know about the overall system layout.
Form Beans.
Bean Tags.
Struts provides a set of custom JSP tags that let you easily output the properties of JavaBeans components.
HTML Tags.
Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This bean/form association serves two useful purposes:
It lets you get initial form-field values from Java objects.
It lets you redisplay forms with some or all previously entered values intact.
Form Field Validation.
Struts has a robust, extensible validator that can be used to uniformly validate your form fields. This validation can be performed on the server (in Java), or both on the server and on the client (in JavaScript).
"Plumbing code" contained within the Struts framework.
Mapping HTTP request parameters to Java objects is handled by Struts, for example. You don't have to do it. This allows you to focus more on the domain problem instead of building infrastructure.
Good documentation & plenty of books.
If you have to leave the project and/or someone else has to maintain it then using a well known and well documented framework will make that job much easier. A homebrewed framework just can't match that.
Broad user testing.
Since Struts is used in plenty web-apps the framework will get looked at by many more eyes than anything you could write alone. Usually, but not always, that means any problems you have will have been seen by someone else (and hopefully resolved) first.
Large knowledge base.
I agree that this perhaps isn't as valid as it used to be but Struts has been used in a lot of projects over the years. From a maintainability point of view using a well known framework makes it easier for other people to work on your application and also help build your own resumé for the future. Right now most development is either in the component based space (like JSF, wicket, tapestry) or in the rails-like space (like rails, grails, lift) but the struts arcitechture is still in use and valid.
You didn't say if you develop in a corporate environment or not, for a personal project perhaps the maintainability issue isn't that much of a problem.
If you decide that struts suits you well you could also have a look at stripes, a struts-like framework that's based on the same concepts but is less verbose when it comes to configuration with more sensible defaults, less xml and support for annotations.
I totally agree with your points about Struts - personally I think its time has come and gone.
I went off Struts in v1 (which I believe is nothing like the latest versions) because the form beans where just added boilerplate code to write.
Since then most applications I've worked on are using Spring as the dependency injection framework, which has made Spring MVC the natural choice - it's simple, straight forward and minimal.
Not just for Struts. But some points to consider for using a framework:
Standarization.
Specialized IDE or plugins for your favourite IDE.
Portability. For example, someone can develope a portlet for integrate your existing struts application in a portal server.
Internationalization.
The most important for me:
You dont have to worry about the issues on the struts code, just upgrade.
You can focus your work in business logic.
Struts is Open Source--
Large Community----
Number of Books available-----
Proven FrameWork----
Popular framework-----
Available since 2001----
+----
the features mentioned above...........
but when u r using struts,the better choice is struts2.
I think your feeling about removing Struts is a sound and understandable reaction. Struts just doesn't seem to do very much for an application.
We've got a legacy app to support. It's pure JSP, i.e. JSP opens connections, does business logic, submits forms (usually to the same JSP), and so on. It's 400+ pages, with some pages are as large as 100K.
The app is expected to be extended and modified over the next few years, so we're looking into ways to split presentation and business logic to simplify the maintenance. At the very minimum we'd like to port it into some simple MVC framework (Struts is #1 candidate).
Nobody is enthusiastic to refactor every page manually. We had an idea that may be somewhere there is a tool that does at least the partial refactoring, e.g. creates ActionForm based on request.getParameter() calls in JSP, moves all Java code into Action (though uncompilable), replaces some "<% if" with <c:if tags, and so on.
The remaining work is still very boring, but at least it has a much smaller scope.
Does anyone know such a tool?
I don't think it worths it. You're saying you have 400+ pages with some beyond 100k?
100k!!!
Probably the best approach is to take a good analysis on that webapp, and modularize it. You can have totally new modules written in other frameworks and still be used in conjunction.
For the pages that are 100K, they are good candidates of their own modules.
I don't really see any advantage of simply translate the whole JSP mess into some other framework mess. What will happen is that simply it will broke into pieces and nobody will feel like fixing them.
The good part is? What modules will go first? What other should not change?
I would start with those that have had more changes in the last months. The fact a file is 100K only means that new features have to be added, but the model was so badly designed, that instead of creating new objects, some code was simply copy/pasted and placed with an if ( I almost feel like I have seen your code already ) and the file grow and grow.
Some parts seems easy to migrate, but the source control says no one have touched in 2 yrs. leave them alone.
More than using a nice framework. you should migrate and re-write the most impacted parts of the system, and create test cases this time.
Also, you should create a project style and validate it automatically with something like checkstyle, so nobody commits new quick patches.
Eventually not all the application will be migrated, but the new changes will be easier to perform, and the application easier to maintain.
I'm currently building a Spring MVC application. I was looking to use JSP pages with tag libraries for handling the view layer and formatting of the HTML, but I've come across another group in my company that uses Velocity templates for the same purpose.
From what I can see, it seems to me as if there are a lot of similarities between the two approaches:
Both have easy-to-understand syntax. Makes it easy for non-developers to understand and use, allowing the designers to focus on the HTML/CSS and only having to use directives/tag libraries in the few cases where they need conditionals/dynamic content without having to have a full understanding of Java.
Simple to see which part of the content is HTML vs which are directives/logic.
Both are heavily used and well supported.
Simple to integrate with Spring MVC.
But in comparing the two technologies, I can't see any specific reasons to use one versus the other. I'm having trouble thinking of any cons specific to either Velocity or JSTL.
So my question is, what are the pros and cons of each in your opinion? If you have built a (Spring) MVC app using one or the other, what made you decide on the view layer technology you are using and what (if anything) made you decide against the other?
Update: I've found a similar discussion of this same topic archived on the Spring Framework forum's here, which might be of some interest to anyone making the same decision between JSTL and Velocity as I am.
I would prefer to use Velocity just because using JSP+JSTL can allow lazy/sloppy developers to get into trouble by adding scriptlets. There should be no reason to have java code in your view tier. It doesn't take much to understand Velocity and as a matter of fact I just picked it up in about two weeks. While I don't like the formatting of the output, for the most part it works pretty well. We're actually not using it in the app's view tier but rather for generating HTML for use by other browsers. We save the output from Velocity as files which is then deployed to a different server for consumption by other web clients.
I actually slightly prefer Freemarker to Velocity, just in case you're open to exploring other options. Comparison here:
http://freemarker.org/fmVsVel.html
I agree with Ben's statements about enforcing a simple view by avoiding JSP and the possibility of scriptlets. I also like the ability to render a Freemarker or Velocity template in any kind of execution environment (JUnit, main() method) without requiring a Servlet/JSP container as JSP would.
JSP is also more difficult to visually differentiate from the embedded HTML. With Velocity, it is very obvious.
Also, the VelocityTools package provides a great deal of additional functionality.