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/
Related
I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
Difference between Request MVC and Component MVC
Difference between JSP, Servlet and JSF
What are the main disadvantages of JSF 2.0?
Is it possible to use JSF+Facelets with HTML 4/5?
When to use <ui:include>, tag files, composite components and/or custom components?
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
Here are the biggest differences between jQuery & JSF:
no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
no (default) validation library
no templating library
no advanced navigation/routing
client side
jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.
And it should thus mostly be used to add behaviour on HTML elements.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.
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>
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.
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.