Using HTML builders in grails instead of GSP - java

is there a way to use groovy builders to build JSP files in a Grails application keeping things enough integrated?
To explain better: by default Grails uses gsp files that are nice but quite verbose..
<div class="clear">
<ul id="nav">
<li><g:link controller="snippets" action="list">Snippets</g:link></li>
<li><g:link controller="users" action="list">Users</g:link></li>
<li><g:link controller="problems" action="list">Problems</g:link></li>
<li><g:link controller="messages" action="list">Messages</g:link></li>
</div>
<div id="content">
is there a way to use groovy.xml.MarkupBuilder tha would turn the previous piece into
div(class:'clear') {
ul(id:'nav') {
li { g_link(controller:'snippets', action:'list', 'Snippets') }
// and so on
Of course g_link is invented just to give the idea..

Do a search for builder under the web layer section of the grails user guide. There is an example in there that shows you exactly how to do this using the xml builder.

I don't have a complete answer for you, but I suspect the key will be gaining access to the "view resolvers". In a normal SpringMVC app, these are configured in views.properties (or views.xml) as follows:
csv=com.example.MyCSVResolver
xml=com.example.MyXMLResolver
audio=com.example.MySpeechResolver
In a regular SpringMVC app, you return something like new ModelAndView(myModel, 'csv') from a controller action.
This would cause the CSVResolver class to be invoked passing it the data in myModel. In addition to containing the data to be rendered, myModel would likely also contain some formatting options (e.g. column widths).
Spring searches the views file for a key matching the view name. If it doesn't find a match, by default it just renders a JSP with the view name and passes it the model data.
Now back to Grails....remember that Grails is really just a Groovy API over SpringMVC and most of the features of SpringMVC can be accessed from Grails. So if you can figure out how to modify the views file, just change your controller actions to return an appropriate ModelAndView instance, and it should work as described above.

GSP allows you to run arbitrary Groovy code inside <% %> brackets. So you can have something like this (borrowing example from page linked to by BlackTiger):
<% StringWriter w = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(w)
builder.html{
head{
title 'Log in'
}
body{
h1 'Hello'
builder.form{ }
}
}
out << w.toString()
%>
Note that the above calls g:form tag, and you can pass additional stuff to it.
So what you are asking for is certainly possible, though I am not sure if it will end up being a win. I'd suggest you perhaps look more at TagLibs in combination with Templates and SiteMesh Layouts - can definitely simplify things tremendously.

Related

JSP, HTML and Servlet [duplicate]

I know that something like the following three lines
<%= x+1 %>
<%= request.getParameter("name") %>
<%! counter++; %>
is an old school way of coding and in JSP version 2 there exists a method to avoid Java code in JSP files. What are the alternative JSP 2 lines, and what is this technique called?
The use of scriptlets (those <% %> things) in JSP is indeed highly discouraged since the birth of taglibs (like JSTL) and EL (Expression Language, those ${} things) way back in 2001.
The major disadvantages of scriptlets are:
Reusability: you can't reuse scriptlets.
Replaceability: you can't make scriptlets abstract.
OO-ability: you can't make use of inheritance/composition.
Debuggability: if scriptlet throws an exception halfway, all you get is a blank page.
Testability: scriptlets are not unit-testable.
Maintainability: per saldo more time is needed to maintain mingled/cluttered/duplicated code logic.
Sun Oracle itself also recommends in the JSP coding conventions to avoid use of scriptlets whenever the same functionality is possible by (tag) classes. Here are several cites of relevance:
From JSP 1.2 Specification, it is highly recommended that the JSP Standard Tag Library (JSTL) be used in your web application to help reduce the need for JSP scriptlets in your pages. Pages that use JSTL are, in general, easier to read and maintain.
...
Where possible, avoid JSP scriptlets whenever tag libraries provide equivalent functionality. This makes pages easier to read and maintain, helps to separate business logic from presentation logic, and will make your pages easier to evolve into JSP 2.0-style pages (JSP 2.0 Specification supports but de-emphasizes the use of scriptlets).
...
In the spirit of adopting the model-view-controller (MVC) design pattern to reduce coupling between the presentation tier from the business logic, JSP scriptlets should not be used for writing business logic. Rather, JSP scriptlets are used if necessary to transform data (also called "value objects") returned from processing the client's requests into a proper client-ready format. Even then, this would be better done with a front controller servlet or a custom tag.
How to replace scriptlets entirely depends on the sole purpose of the code/logic. More than often this code is to be placed in a fullworthy Java class:
If you want to invoke the same Java code on every request, less-or-more regardless of the requested page, e.g. checking if a user is logged in, then implement a filter and write code accordingly in doFilter() method. E.g.:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
if (((HttpServletRequest) request).getSession().getAttribute("user") == null) {
((HttpServletResponse) response).sendRedirect("login"); // Not logged in, redirect to login page.
} else {
chain.doFilter(request, response); // Logged in, just continue request.
}
}
When mapped on an appropriate <url-pattern> covering the JSP pages of interest, then you don't need to copypaste the same piece of code overall JSP pages.
If you want to invoke some Java code to process a GET request, e.g. preloading some list from a database to display in some table, if necessary based on some query parameters, then implement a servlet and write code accordingly in doGet() method. E.g.:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
List<Product> products = productService.list(); // Obtain all products.
request.setAttribute("products", products); // Store products in request scope.
request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response); // Forward to JSP page to display them in a HTML table.
} catch (SQLException e) {
throw new ServletException("Retrieving products failed!", e);
}
}
This way dealing with exceptions is easier. The DB is not accessed in the midst of JSP rendering, but far before the JSP is been displayed. You still have the possibility to change the response whenever the DB access throws an exception. In the above example, the default error 500 page will be displayed which you can anyway customize by an <error-page> in web.xml.
If you want to invoke some Java code to process a POST request, such as gathering data from a submitted HTML form and doing some business stuff with it (conversion, validation, saving in DB, etcetera), then implement a servlet and write code accordingly in doPost() method. E.g.:
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
String password = request.getParameter("password");
User user = userService.find(username, password);
if (user != null) {
request.getSession().setAttribute("user", user); // Login user.
response.sendRedirect("home"); // Redirect to home page.
} else {
request.setAttribute("message", "Unknown username/password. Please retry."); // Store error message in request scope.
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to JSP page to redisplay login form with error.
}
}
This way dealing with different result page destinations is easier: redisplaying the form with validation errors in case of an error (in this particular example you can redisplay it using ${message} in EL), or just taking to the desired target page in case of success.
If you want to invoke some Java code to control the execution plan and/or the destination of the request and the response, then implement a servlet according to the MVC's Front Controller Pattern. E.g.:
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
Action action = ActionFactory.getAction(request);
String view = action.execute(request, response);
if (view.equals(request.getPathInfo().substring(1)) {
request.getRequestDispatcher("/WEB-INF/" + view + ".jsp").forward(request, response);
} else {
response.sendRedirect(view);
}
} catch (Exception e) {
throw new ServletException("Executing action failed.", e);
}
}
Or just adopt an MVC framework like JSF, Spring MVC, Wicket, etc so that you end up with just a JSP/Facelets page and a JavaBean class without the need for a custom servlet.
If you want to invoke some Java code to control the flow inside a JSP page, then you need to grab an (existing) flow control taglib like JSTL core. E.g. displaying List<Product> in a table:
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<table>
<c:forEach items="${products}" var="product">
<tr>
<td>${product.name}</td>
<td>${product.description}</td>
<td>${product.price}</td>
</tr>
</c:forEach>
</table>
With XML-style tags which fit nicely among all that HTML, the code is better readable (and thus better maintainable) than a bunch of scriptlets with various opening and closing braces ("Where the heck does this closing brace belong to?"). An easy aid is to configure your web application to throw an exception whenever scriptlets are still been used by adding the following piece to web.xml:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>
In Facelets, the successor of JSP, which is part of the Java EE provided MVC framework JSF, it is already not possible to use scriptlets. This way you're automatically forced to do things "the right way".
If you want to invoke some Java code to access and display "backend" data inside a JSP page, then you need to use EL (Expression Language), those ${} things. E.g. redisplaying submitted input values:
<input type="text" name="foo" value="${param.foo}" />
The ${param.foo} displays the outcome of request.getParameter("foo").
If you want to invoke some utility Java code directly in the JSP page (typically public static methods), then you need to define them as EL functions. There's a standard functions taglib in JSTL, but you can also easily create functions yourself. Here's an example how JSTL fn:escapeXml is useful to prevent XSS attacks.
<%# taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input type="text" name="foo" value="${fn:escapeXml(param.foo)}" />
Note that the XSS sensitivity is in no way specifically related to Java/JSP/JSTL/EL/whatever, this problem needs to be taken into account in every web application you develop. The problem of scriptlets is that it provides no way of builtin preventions, at least not using the standard Java API. JSP's successor Facelets has already implicit HTML escaping, so you don't need to worry about XSS holes in Facelets.
See also:
What's the difference between JSP, Servlet and JSF?
How does Servlet, ServletContext, HttpSession and HttpServletRequest/Response work?
Basic MVC example with JSP, Servlet and JDBC
Design patterns in Java web applications
Hidden features of JSP/Servlet
As a Safeguard: Disable Scriptlets For Good
As another question is discussing, you can and always should disable scriptlets in your web.xml web application descriptor.
I would always do that in order to prevent any developer adding scriptlets, especially in bigger companies where you will lose overview sooner or later. The web.xml settings look like this:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>
JSTL offers tags for conditionals, loops, sets, gets, etc. For example:
<c:if test="${someAttribute == 'something'}">
...
</c:if>
JSTL works with request attributes - they are most often set in the request by a Servlet, which forwards to the JSP.
You can use JSTL tags together with EL expressions to avoid intermixing Java and HTML code:
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<html>
<head>
</head>
<body>
<c:out value="${x + 1}" />
<c:out value="${param.name}" />
// and so on
</body>
</html>
There are also component-based frameworks, such as Wicket, that generate a lot of the HTML for you.
The tags that end up in the HTML are extremely basic and there is virtually no logic that gets mixed in. The result is almost empty-like HTML pages with typical HTML elements. The downside is that there are a lot of components in the Wicket API to learn and some things can be difficult to achieve under those constraints.
In the MVC architectural pattern, JSPs represent the view layer. Embedding Java code in JSPs is considered a bad practice.
You can use JSTL, freeMarker, and velocity with JSP as a "template engine".
The data provider to those tags depends on frameworks that you are dealing with. Struts 2 and WebWork as an implementation for the MVC pattern uses OGNL "very interesting technique to expose Beans properties to JSP".
Experience has shown that JSP's have some shortcomings, one of them being hard to avoid mixing markup with actual code.
If you can, then consider using a specialized technology for what you need to do. In Java EE 6 there is JSF 2.0, which provides a lot of nice features including gluing Java beans together with JSF pages through the #{bean.method(argument)} approach.
If you simply want to avoid the drawbacks of Java coding in JSP you can do so even with scriplets. Just follow some discipline to have minimal Java in JSP and almost no calculation and logic in the JSP page.
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<% // Instantiate a JSP controller
MyController clr = new MyController(request, response);
// Process action, if any
clr.process(request);
// Process page forwarding, if necessary
// Do all variable assignment here
String showMe = clr.getShowMe();%>
<html>
<head>
</head>
<body>
<form name="frm1">
<p><%= showMe %>
<p><% for(String str : clr.listOfStrings()) { %>
<p><%= str %><% } %>
// And so on
</form>
</body>
</html>
Learn to customize and write your own tags using JSTL
Note that EL is EviL (runtime exceptions and refactoring).
Wicket may be evil too (performance and toilsome for small applications or simple view tier).
Example from java2s
This must be added to the web application's web.xml
<taglib>
<taglib-uri>/java2s</taglib-uri>
<taglib-location>/WEB-INF/java2s.tld</taglib-location>
</taglib>
Create file java2s.tld in the /WEB-INF/
<!DOCTYPE taglib
PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
"http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">
<!-- A tab library descriptor -->
<taglib xmlns="http://java.sun.com/JSP/TagLibraryDescriptor">
<tlib-version>1.0</tlib-version>
<jsp-version>1.2</jsp-version>
<short-name>Java2s Simple Tags</short-name>
<!-- This tag manipulates its body content by converting it to upper case
-->
<tag>
<name>bodyContentTag</name>
<tag-class>com.java2s.BodyContentTag</tag-class>
<body-content>JSP</body-content>
<attribute>
<name>howMany</name>
</attribute>
</tag>
</taglib>
Compile the following code into WEB-INF\classes\com\java2s
package com.java2s;
import java.io.IOException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.tagext.BodyTagSupport;
public class BodyContentTag extends BodyTagSupport{
private int iterations, howMany;
public void setHowMany(int i){
this.howMany = i;
}
public void setBodyContent(BodyContent bc){
super.setBodyContent(bc);
System.out.println("BodyContent = '" + bc.getString() + "'");
}
public int doAfterBody(){
try{
BodyContent bodyContent = super.getBodyContent();
String bodyString = bodyContent.getString();
JspWriter out = bodyContent.getEnclosingWriter();
if ( iterations % 2 == 0 )
out.print(bodyString.toLowerCase());
else
out.print(bodyString.toUpperCase());
iterations++;
bodyContent.clear(); // empty buffer for next evaluation
}
catch (IOException e) {
System.out.println("Error in BodyContentTag.doAfterBody()" + e.getMessage());
e.printStackTrace();
} // End of catch
int retValue = SKIP_BODY;
if ( iterations < howMany )
retValue = EVAL_BODY_AGAIN;
return retValue;
}
}
Start the server and load the bodyContent.jsp file in the browser:
<%# taglib uri="/java2s" prefix="java2s" %>
<html>
<head>
<title>A custom tag: body content</title>
</head>
<body>
This page uses a custom tag manipulates its body content.Here is its output:
<ol>
<java2s:bodyContentTag howMany="3">
<li>java2s.com</li>
</java2s:bodyContentTag>
</ol>
</body>
</html>
Wicket is also an alternative which completely separates Java from HTML, so a designer and programmer can work together and on different sets of code with little understanding of each other.
Look at Wicket.
You raised a good question and although you got good answers, I would suggest that you get rid of JSP. It is outdated technology which eventually will die. Use a modern approach, like template engines. You will have very clear separation of business and presentation layers, and certainly no Java code in templates, so you can generate templates directly from web presentation editing software, in most cases leveraging WYSIWYG.
And certainly stay away of filters and pre and post processing, otherwise you may deal with support/debugging difficulties since you always do not know where the variable gets the value.
In order to avoid Java code in JSP files, Java now provides tag libraries, like JSTL.
Also, Java has come up with JSF into which you can write all programming structures in the form of tags.
No matter how much you try to avoid, when you work with other developers, some of them will still prefer scriptlet and then insert the evil code into the project. Therefore, setting up the project at the first sign is very important if you really want to reduce the scriptlet code. There are several techniques to get over this (including several frameworks that other mentioned). However, if you prefer the pure JSP way, then use the JSTL tag file. The nice thing about this is you can also set up master pages for your project, so the other pages can inherit the master pages
Create a master page called base.tag under your WEB-INF/tags with the following content
<%#tag description="Overall Page template" pageEncoding="UTF-8"%>
<%#attribute name="title" fragment="true" %>
<html>
<head>
<title>
<jsp:invoke fragment="title"></jsp:invoke>
</title>
</head>
<body>
<div id="page-header">
....
</div>
<div id="page-body">
<jsp:doBody/>
</div>
<div id="page-footer">
.....
</div>
</body>
</html>
On this mater page, I created a fragment called "title", so that in the child page, I could insert more codes into this place of the master page. Also, the tag <jsp:doBody/> will be replaced by the content of the child page
Create child page (child.jsp) in your WebContent folder:
<%# taglib prefix="t" tagdir="/WEB-INF/tags" %>
<t:base>
<jsp:attribute name="title">
<bean:message key="hello.world" />
</jsp:attribute>
<jsp:body>
[Put your content of the child here]
</jsp:body>
</t:base>
<t:base> is used to specify the master page you want to use (which is base.tag at this moment). All the content inside the tag <jsp:body> here will replace the <jsp:doBody/> on your master page. Your child page can also include any tag lib and you can use it normally like the other mentioned. However, if you use any scriptlet code here (<%= request.getParameter("name") %> ...) and try to run this page, you will get a JasperException because Scripting elements ( <%!, <jsp:declaration, <%=, <jsp:expression, <%, <jsp:scriptlet ) are disallowed here. Therefore, there is no way other people can include the evil code into the jsp file
Calling this page from your controller:
You can easily call the child.jsp file from your controller. This also works nice with the struts framework
Use JSTL tag libraries in JSP. That will work perfectly.
Just use the JSTL tag and EL expression.
If somebody is really against programming in more languages than one, I suggest GWT. Theoretically, you can avoid all the JavaScript and HTML elements, because Google Toolkit transforms all the client and shared code to JavaScript. You won't have problem with them, so you have a webservice without coding in any other languages. You can even use some default CSS from somewhere as it is given by extensions (smartGWT or Vaadin). You don't need to learn dozens of annotations.
Of course, if you want, you can hack yourself into the depths of the code and inject JavaScript and enrich your HTML page, but really you can avoid it if you want, and the result will be good as it was written in any other frameworks. I it's say worth a try, and the basic GWT is well-documented.
And of course many fellow programmers hereby described or recommended several other solutions. GWT is for people who really don't want to deal with the web part or to minimize it.
Using scriptlets in JSPs is not a good practice.
Instead, you can use:
JSTL tags
EL expressions
Custom Tags- you can define your own tags to use.
Please refer to:
http://docs.oracle.com/javaee/1.4/tutorial/doc/JSTL3.html
EL
A neat idea from the Python world is Template attribute languages; TAL was introduced by Zope (therefore a.k.a. "Zope Page Templates", ZPT) and is a standard, with implementations in PHP, XSLT and Java as well (I have used the Python/Zope and PHP incarnations). In this class of templating languages, one of the above examples could look like this:
<table>
<tr tal:repeat="product products">
<td tal:content="product/name">Example product</td>
<td tal:content="product/description">A nice description</td>
<td tal:content="product/price">1.23</td>
</tr>
</table>
The code looks like ordinary HTML (or XHTML) plus some special attributes in an XML namespace; it can be viewed with a browser and safely be tweaked by a designer.
There is support for macros and for internationalisation and localisation as well:
<h1 i18n:translate="">Our special offers</h1>
<table>
<tr tal:repeat="product products">
<td tal:content="product/name"
i18n:translate="">Example product</td>
<td tal:content="product/description"
i18n:translate="">A nice description</td>
<td tal:content="product/price">1.23</td>
</tr>
</table>
If translations of the content are available, they are used.
I don't know very much about the Java implementation, though.
Sure, replace <%! counter++; %> by an event producer-consumer architecture, where the business layer is notified about the need to increment the counter, it reacts accordingly, and notifies the presenters so that they update the views. A number of database transactions are involved, since in future we will need to know the new and old value of the counter, who has incremented it and with what purpose in mind. Obviously serialization is involved, since the layers are entirely decoupled. You will be able to increment your counter over RMI, IIOP, SOAP. But only HTML is required, which you don't implement, since it is such a mundane case. Your new goal is to reach 250 increments a second on your new shiny E7, 64GB RAM server.
I have more than 20 years in programming, most of the projects fail before the sextet: Reusability Replaceability OO-ability Debuggability Testability Maintainability is even needed. Other projects, run by people who only cared about functionality, were extremely successful. Also, stiff object structure, implemented too early in the project, makes the code unable to be adapted to the drastic changes in the specifications (aka agile).
So I consider as procrastination the activity of defining "layers" or redundant data structures either early in the project or when not specifically required.
Technically, JSP are all converted to Servlets during runtime.
JSP was initially created for the purpose of the decoupling the business logic and the design logic, following the MVC pattern. So JSP is technically all Java code during runtime.
But to answer the question, tag libraries are usually used for applying logic (removing Java code) to JSP pages.
How can I avoid Java code in JSP files?
You can use tab library tags like JSTL in addition to Expression Language (EL). But EL does not work well with JSP. So it's is probably better to drop JSP completely and use Facelets.
Facelets is the first non JSP page declaration language designed for JSF (Java Server Faces) which provided a simpler and more powerful programming model to JSF developers as compare to JSP. It resolves different issues occurs in JSP for web applications development.
Source
If we use the following things in a Java web application, Java code can be eliminated from the foreground of the JSP file.
Use the MVC architecture for a web application
Use JSP Tags
a. Standard Tags
b. Custom Tags
Expression Language
Using Scriptlets is a very old way and not recommended. If you want directly output something in your JSP pages, just use Expression Language (EL) along with JSTL.
There are also other options, such as using a templating engine such as Velocity, Freemarker, Thymeleaf, etc. But using plain JSP with EL and JSTL serves my purpose most of the time and it also seems the simplest for a beginner.
Also, take note that it is not a best practice to do business logic in the view layer. You should perform your business logic in the service layer,
and pass the output result to your views through a controller.
Use a Backbone.js or AngularJS-like JavaScript framework for UI design
and fetch the data using a REST API. This will remove the Java dependency from the UI completely.
Nothing of that is used anymore, my friend. My advice is to decouple the view (CSS, HTML, JavaScript, etc.) from the server.
In my case, I do my systems handling the view with Angular and any data needed is brought from the server using REST services.
Believe me, this will change the way you design.
JSP 2.0 has a feature called "Tag Files", and you can write tags without external Java code and tld. You need to create a .tag file and put it in WEB-INF\tags. You can even create a directory structure to package your tags.
For example:
/WEB-INF/tags/html/label.tag
<%#tag description="Rensders a label with required css class" pageEncoding="UTF-8"%>
<%#attribute name="name" required="true" description="The label"%>
<label class="control-label control-default" id="${name}Label">${name}</label>
Use it like
<%# taglib prefix="h" tagdir="/WEB-INF/tags/html"%>
<h:label name="customer name" />
Also, you can read the tag body easily:
/WEB-INF/tags/html/bold.tag
<%#tag description="Bold tag" pageEncoding="UTF-8"%>
<b>
<jsp:doBody/>
</b>
Use it:
<%# taglib prefix="h" tagdir="/WEB-INF/tags/bold"%>
<h:bold>Make me bold</h:bold>
The samples are very simple, but you can do lots of complicated tasks here. Please consider you can use other tags (for example: JSTL which has controlling tags like if/forEcah/chosen text manipulation like format/contains/uppercase or even SQL tags select/update), pass all kind parameters, for example Hashmap, access session, request, ... in your tag file too.
Tag File are so easy developed as you did not need to restart the server when changing them, like JSP files. This makes them easy for development.
Even if you use a framework like Struts 2, which have lots of good tags, you may find that having your own tags can reduce your code a lot. You can pass your tag parameters to struts and this way customize your framework tag.
You can use tags not only to avoid Java, but also minimize your HTML codes. I myself try to review HTML code and build tags a lot as soon as I see code duplicates start in my pages.
(Even if you end up using Java in your JSP code, which I hope not, you can encapsulate that code in a tag.)
Make your values and parameters inside your servlet classes
Fetch those values and parameters within your JSP using JSTL/Taglib
The good thing about this approach is that your code is also HTML like
code!
A lot of the answers here go the "use a framework" route. There's zero wrong with that. However I don't think it really answers your question, because frameworks may or may not use JSPs, nor are they designed in any way with removing java use in JSPs as a primary goal.
The only good answer to your question "how do I avoid using Java in a JSP" is: you can't. That's what JSPs are for - using Java to render HTML with dynamic data/logic.
The follow up question might be, how much java should I use in my JSPs. Before we answer that question, you should also ponder, "do I need to use JSPs to build web content using Java?" The answer to that last one is, no. There are many alternatives to JSPs for developing web facing applications using Java. Struts for example does not force you to use JSPs - don't get me wrong, you can use them and many implementations do, but you don't absolutely have to. Struts doesn't even force you to use any HTML. A JSP doesn't either, but let's be honest, a JSP producing no HTML is kinda weird. Servlets, famously, allow you to serve any kind of content you like over HTTP dynamically. They are the primary tech behind pretty much everything java web - JSPs are just HTML templates for servlets, really.
So the answer to how much java you should put in a JSP is, "as little as possible". I of course have java in my JSPs, but it consists exclusively of tag library definitions, session and client variables, and beans encapsulating server side objects. The <%%> tags in my HTML are almost exclusively property calls or variable expressions. Rare exceptions include ultra-specific calculations pertaining to a single page and unlikely to ever be reused; bugfixes stemming from page-specific issues only applying to one page; last minute concatenations and arithmetic stemming from unusual requirements limited in scope to a single page; and other similar cases. In a code set of 1.5 million lines, 3000 JSPs and 5000 classes, there are maybe 100 instances of such unique snippets. It would have been quite possible to make these changes in classes or tag library definitions, but it would have been inordinately complex due to the specificity of each case, taken longer to write and debug, and taken more time as a result to get to my users. It's a judgement call. But make no mistake, you cannot write JSPs of any meaning with "no java" nor would you want to. The capability is there for a reason.
As many answers says, use JSTL or create your own custom tags. Here is a good explanation about creating custom tags.
By using JSTL tags together with EL expressions, you can avoid this. Put the following things in your JSP page:
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

Confusion between using the EL exp tag and JSP expression tags with JSTL [duplicate]

I know that something like the following three lines
<%= x+1 %>
<%= request.getParameter("name") %>
<%! counter++; %>
is an old school way of coding and in JSP version 2 there exists a method to avoid Java code in JSP files. What are the alternative JSP 2 lines, and what is this technique called?
The use of scriptlets (those <% %> things) in JSP is indeed highly discouraged since the birth of taglibs (like JSTL) and EL (Expression Language, those ${} things) way back in 2001.
The major disadvantages of scriptlets are:
Reusability: you can't reuse scriptlets.
Replaceability: you can't make scriptlets abstract.
OO-ability: you can't make use of inheritance/composition.
Debuggability: if scriptlet throws an exception halfway, all you get is a blank page.
Testability: scriptlets are not unit-testable.
Maintainability: per saldo more time is needed to maintain mingled/cluttered/duplicated code logic.
Sun Oracle itself also recommends in the JSP coding conventions to avoid use of scriptlets whenever the same functionality is possible by (tag) classes. Here are several cites of relevance:
From JSP 1.2 Specification, it is highly recommended that the JSP Standard Tag Library (JSTL) be used in your web application to help reduce the need for JSP scriptlets in your pages. Pages that use JSTL are, in general, easier to read and maintain.
...
Where possible, avoid JSP scriptlets whenever tag libraries provide equivalent functionality. This makes pages easier to read and maintain, helps to separate business logic from presentation logic, and will make your pages easier to evolve into JSP 2.0-style pages (JSP 2.0 Specification supports but de-emphasizes the use of scriptlets).
...
In the spirit of adopting the model-view-controller (MVC) design pattern to reduce coupling between the presentation tier from the business logic, JSP scriptlets should not be used for writing business logic. Rather, JSP scriptlets are used if necessary to transform data (also called "value objects") returned from processing the client's requests into a proper client-ready format. Even then, this would be better done with a front controller servlet or a custom tag.
How to replace scriptlets entirely depends on the sole purpose of the code/logic. More than often this code is to be placed in a fullworthy Java class:
If you want to invoke the same Java code on every request, less-or-more regardless of the requested page, e.g. checking if a user is logged in, then implement a filter and write code accordingly in doFilter() method. E.g.:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
if (((HttpServletRequest) request).getSession().getAttribute("user") == null) {
((HttpServletResponse) response).sendRedirect("login"); // Not logged in, redirect to login page.
} else {
chain.doFilter(request, response); // Logged in, just continue request.
}
}
When mapped on an appropriate <url-pattern> covering the JSP pages of interest, then you don't need to copypaste the same piece of code overall JSP pages.
If you want to invoke some Java code to process a GET request, e.g. preloading some list from a database to display in some table, if necessary based on some query parameters, then implement a servlet and write code accordingly in doGet() method. E.g.:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
List<Product> products = productService.list(); // Obtain all products.
request.setAttribute("products", products); // Store products in request scope.
request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response); // Forward to JSP page to display them in a HTML table.
} catch (SQLException e) {
throw new ServletException("Retrieving products failed!", e);
}
}
This way dealing with exceptions is easier. The DB is not accessed in the midst of JSP rendering, but far before the JSP is been displayed. You still have the possibility to change the response whenever the DB access throws an exception. In the above example, the default error 500 page will be displayed which you can anyway customize by an <error-page> in web.xml.
If you want to invoke some Java code to process a POST request, such as gathering data from a submitted HTML form and doing some business stuff with it (conversion, validation, saving in DB, etcetera), then implement a servlet and write code accordingly in doPost() method. E.g.:
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
String password = request.getParameter("password");
User user = userService.find(username, password);
if (user != null) {
request.getSession().setAttribute("user", user); // Login user.
response.sendRedirect("home"); // Redirect to home page.
} else {
request.setAttribute("message", "Unknown username/password. Please retry."); // Store error message in request scope.
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to JSP page to redisplay login form with error.
}
}
This way dealing with different result page destinations is easier: redisplaying the form with validation errors in case of an error (in this particular example you can redisplay it using ${message} in EL), or just taking to the desired target page in case of success.
If you want to invoke some Java code to control the execution plan and/or the destination of the request and the response, then implement a servlet according to the MVC's Front Controller Pattern. E.g.:
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
Action action = ActionFactory.getAction(request);
String view = action.execute(request, response);
if (view.equals(request.getPathInfo().substring(1)) {
request.getRequestDispatcher("/WEB-INF/" + view + ".jsp").forward(request, response);
} else {
response.sendRedirect(view);
}
} catch (Exception e) {
throw new ServletException("Executing action failed.", e);
}
}
Or just adopt an MVC framework like JSF, Spring MVC, Wicket, etc so that you end up with just a JSP/Facelets page and a JavaBean class without the need for a custom servlet.
If you want to invoke some Java code to control the flow inside a JSP page, then you need to grab an (existing) flow control taglib like JSTL core. E.g. displaying List<Product> in a table:
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<table>
<c:forEach items="${products}" var="product">
<tr>
<td>${product.name}</td>
<td>${product.description}</td>
<td>${product.price}</td>
</tr>
</c:forEach>
</table>
With XML-style tags which fit nicely among all that HTML, the code is better readable (and thus better maintainable) than a bunch of scriptlets with various opening and closing braces ("Where the heck does this closing brace belong to?"). An easy aid is to configure your web application to throw an exception whenever scriptlets are still been used by adding the following piece to web.xml:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>
In Facelets, the successor of JSP, which is part of the Java EE provided MVC framework JSF, it is already not possible to use scriptlets. This way you're automatically forced to do things "the right way".
If you want to invoke some Java code to access and display "backend" data inside a JSP page, then you need to use EL (Expression Language), those ${} things. E.g. redisplaying submitted input values:
<input type="text" name="foo" value="${param.foo}" />
The ${param.foo} displays the outcome of request.getParameter("foo").
If you want to invoke some utility Java code directly in the JSP page (typically public static methods), then you need to define them as EL functions. There's a standard functions taglib in JSTL, but you can also easily create functions yourself. Here's an example how JSTL fn:escapeXml is useful to prevent XSS attacks.
<%# taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input type="text" name="foo" value="${fn:escapeXml(param.foo)}" />
Note that the XSS sensitivity is in no way specifically related to Java/JSP/JSTL/EL/whatever, this problem needs to be taken into account in every web application you develop. The problem of scriptlets is that it provides no way of builtin preventions, at least not using the standard Java API. JSP's successor Facelets has already implicit HTML escaping, so you don't need to worry about XSS holes in Facelets.
See also:
What's the difference between JSP, Servlet and JSF?
How does Servlet, ServletContext, HttpSession and HttpServletRequest/Response work?
Basic MVC example with JSP, Servlet and JDBC
Design patterns in Java web applications
Hidden features of JSP/Servlet
As a Safeguard: Disable Scriptlets For Good
As another question is discussing, you can and always should disable scriptlets in your web.xml web application descriptor.
I would always do that in order to prevent any developer adding scriptlets, especially in bigger companies where you will lose overview sooner or later. The web.xml settings look like this:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>
JSTL offers tags for conditionals, loops, sets, gets, etc. For example:
<c:if test="${someAttribute == 'something'}">
...
</c:if>
JSTL works with request attributes - they are most often set in the request by a Servlet, which forwards to the JSP.
You can use JSTL tags together with EL expressions to avoid intermixing Java and HTML code:
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<html>
<head>
</head>
<body>
<c:out value="${x + 1}" />
<c:out value="${param.name}" />
// and so on
</body>
</html>
There are also component-based frameworks, such as Wicket, that generate a lot of the HTML for you.
The tags that end up in the HTML are extremely basic and there is virtually no logic that gets mixed in. The result is almost empty-like HTML pages with typical HTML elements. The downside is that there are a lot of components in the Wicket API to learn and some things can be difficult to achieve under those constraints.
In the MVC architectural pattern, JSPs represent the view layer. Embedding Java code in JSPs is considered a bad practice.
You can use JSTL, freeMarker, and velocity with JSP as a "template engine".
The data provider to those tags depends on frameworks that you are dealing with. Struts 2 and WebWork as an implementation for the MVC pattern uses OGNL "very interesting technique to expose Beans properties to JSP".
Experience has shown that JSP's have some shortcomings, one of them being hard to avoid mixing markup with actual code.
If you can, then consider using a specialized technology for what you need to do. In Java EE 6 there is JSF 2.0, which provides a lot of nice features including gluing Java beans together with JSF pages through the #{bean.method(argument)} approach.
If you simply want to avoid the drawbacks of Java coding in JSP you can do so even with scriplets. Just follow some discipline to have minimal Java in JSP and almost no calculation and logic in the JSP page.
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<% // Instantiate a JSP controller
MyController clr = new MyController(request, response);
// Process action, if any
clr.process(request);
// Process page forwarding, if necessary
// Do all variable assignment here
String showMe = clr.getShowMe();%>
<html>
<head>
</head>
<body>
<form name="frm1">
<p><%= showMe %>
<p><% for(String str : clr.listOfStrings()) { %>
<p><%= str %><% } %>
// And so on
</form>
</body>
</html>
Learn to customize and write your own tags using JSTL
Note that EL is EviL (runtime exceptions and refactoring).
Wicket may be evil too (performance and toilsome for small applications or simple view tier).
Example from java2s
This must be added to the web application's web.xml
<taglib>
<taglib-uri>/java2s</taglib-uri>
<taglib-location>/WEB-INF/java2s.tld</taglib-location>
</taglib>
Create file java2s.tld in the /WEB-INF/
<!DOCTYPE taglib
PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
"http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">
<!-- A tab library descriptor -->
<taglib xmlns="http://java.sun.com/JSP/TagLibraryDescriptor">
<tlib-version>1.0</tlib-version>
<jsp-version>1.2</jsp-version>
<short-name>Java2s Simple Tags</short-name>
<!-- This tag manipulates its body content by converting it to upper case
-->
<tag>
<name>bodyContentTag</name>
<tag-class>com.java2s.BodyContentTag</tag-class>
<body-content>JSP</body-content>
<attribute>
<name>howMany</name>
</attribute>
</tag>
</taglib>
Compile the following code into WEB-INF\classes\com\java2s
package com.java2s;
import java.io.IOException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.tagext.BodyTagSupport;
public class BodyContentTag extends BodyTagSupport{
private int iterations, howMany;
public void setHowMany(int i){
this.howMany = i;
}
public void setBodyContent(BodyContent bc){
super.setBodyContent(bc);
System.out.println("BodyContent = '" + bc.getString() + "'");
}
public int doAfterBody(){
try{
BodyContent bodyContent = super.getBodyContent();
String bodyString = bodyContent.getString();
JspWriter out = bodyContent.getEnclosingWriter();
if ( iterations % 2 == 0 )
out.print(bodyString.toLowerCase());
else
out.print(bodyString.toUpperCase());
iterations++;
bodyContent.clear(); // empty buffer for next evaluation
}
catch (IOException e) {
System.out.println("Error in BodyContentTag.doAfterBody()" + e.getMessage());
e.printStackTrace();
} // End of catch
int retValue = SKIP_BODY;
if ( iterations < howMany )
retValue = EVAL_BODY_AGAIN;
return retValue;
}
}
Start the server and load the bodyContent.jsp file in the browser:
<%# taglib uri="/java2s" prefix="java2s" %>
<html>
<head>
<title>A custom tag: body content</title>
</head>
<body>
This page uses a custom tag manipulates its body content.Here is its output:
<ol>
<java2s:bodyContentTag howMany="3">
<li>java2s.com</li>
</java2s:bodyContentTag>
</ol>
</body>
</html>
Wicket is also an alternative which completely separates Java from HTML, so a designer and programmer can work together and on different sets of code with little understanding of each other.
Look at Wicket.
You raised a good question and although you got good answers, I would suggest that you get rid of JSP. It is outdated technology which eventually will die. Use a modern approach, like template engines. You will have very clear separation of business and presentation layers, and certainly no Java code in templates, so you can generate templates directly from web presentation editing software, in most cases leveraging WYSIWYG.
And certainly stay away of filters and pre and post processing, otherwise you may deal with support/debugging difficulties since you always do not know where the variable gets the value.
In order to avoid Java code in JSP files, Java now provides tag libraries, like JSTL.
Also, Java has come up with JSF into which you can write all programming structures in the form of tags.
No matter how much you try to avoid, when you work with other developers, some of them will still prefer scriptlet and then insert the evil code into the project. Therefore, setting up the project at the first sign is very important if you really want to reduce the scriptlet code. There are several techniques to get over this (including several frameworks that other mentioned). However, if you prefer the pure JSP way, then use the JSTL tag file. The nice thing about this is you can also set up master pages for your project, so the other pages can inherit the master pages
Create a master page called base.tag under your WEB-INF/tags with the following content
<%#tag description="Overall Page template" pageEncoding="UTF-8"%>
<%#attribute name="title" fragment="true" %>
<html>
<head>
<title>
<jsp:invoke fragment="title"></jsp:invoke>
</title>
</head>
<body>
<div id="page-header">
....
</div>
<div id="page-body">
<jsp:doBody/>
</div>
<div id="page-footer">
.....
</div>
</body>
</html>
On this mater page, I created a fragment called "title", so that in the child page, I could insert more codes into this place of the master page. Also, the tag <jsp:doBody/> will be replaced by the content of the child page
Create child page (child.jsp) in your WebContent folder:
<%# taglib prefix="t" tagdir="/WEB-INF/tags" %>
<t:base>
<jsp:attribute name="title">
<bean:message key="hello.world" />
</jsp:attribute>
<jsp:body>
[Put your content of the child here]
</jsp:body>
</t:base>
<t:base> is used to specify the master page you want to use (which is base.tag at this moment). All the content inside the tag <jsp:body> here will replace the <jsp:doBody/> on your master page. Your child page can also include any tag lib and you can use it normally like the other mentioned. However, if you use any scriptlet code here (<%= request.getParameter("name") %> ...) and try to run this page, you will get a JasperException because Scripting elements ( <%!, <jsp:declaration, <%=, <jsp:expression, <%, <jsp:scriptlet ) are disallowed here. Therefore, there is no way other people can include the evil code into the jsp file
Calling this page from your controller:
You can easily call the child.jsp file from your controller. This also works nice with the struts framework
Use JSTL tag libraries in JSP. That will work perfectly.
Just use the JSTL tag and EL expression.
If somebody is really against programming in more languages than one, I suggest GWT. Theoretically, you can avoid all the JavaScript and HTML elements, because Google Toolkit transforms all the client and shared code to JavaScript. You won't have problem with them, so you have a webservice without coding in any other languages. You can even use some default CSS from somewhere as it is given by extensions (smartGWT or Vaadin). You don't need to learn dozens of annotations.
Of course, if you want, you can hack yourself into the depths of the code and inject JavaScript and enrich your HTML page, but really you can avoid it if you want, and the result will be good as it was written in any other frameworks. I it's say worth a try, and the basic GWT is well-documented.
And of course many fellow programmers hereby described or recommended several other solutions. GWT is for people who really don't want to deal with the web part or to minimize it.
Using scriptlets in JSPs is not a good practice.
Instead, you can use:
JSTL tags
EL expressions
Custom Tags- you can define your own tags to use.
Please refer to:
http://docs.oracle.com/javaee/1.4/tutorial/doc/JSTL3.html
EL
A neat idea from the Python world is Template attribute languages; TAL was introduced by Zope (therefore a.k.a. "Zope Page Templates", ZPT) and is a standard, with implementations in PHP, XSLT and Java as well (I have used the Python/Zope and PHP incarnations). In this class of templating languages, one of the above examples could look like this:
<table>
<tr tal:repeat="product products">
<td tal:content="product/name">Example product</td>
<td tal:content="product/description">A nice description</td>
<td tal:content="product/price">1.23</td>
</tr>
</table>
The code looks like ordinary HTML (or XHTML) plus some special attributes in an XML namespace; it can be viewed with a browser and safely be tweaked by a designer.
There is support for macros and for internationalisation and localisation as well:
<h1 i18n:translate="">Our special offers</h1>
<table>
<tr tal:repeat="product products">
<td tal:content="product/name"
i18n:translate="">Example product</td>
<td tal:content="product/description"
i18n:translate="">A nice description</td>
<td tal:content="product/price">1.23</td>
</tr>
</table>
If translations of the content are available, they are used.
I don't know very much about the Java implementation, though.
Sure, replace <%! counter++; %> by an event producer-consumer architecture, where the business layer is notified about the need to increment the counter, it reacts accordingly, and notifies the presenters so that they update the views. A number of database transactions are involved, since in future we will need to know the new and old value of the counter, who has incremented it and with what purpose in mind. Obviously serialization is involved, since the layers are entirely decoupled. You will be able to increment your counter over RMI, IIOP, SOAP. But only HTML is required, which you don't implement, since it is such a mundane case. Your new goal is to reach 250 increments a second on your new shiny E7, 64GB RAM server.
I have more than 20 years in programming, most of the projects fail before the sextet: Reusability Replaceability OO-ability Debuggability Testability Maintainability is even needed. Other projects, run by people who only cared about functionality, were extremely successful. Also, stiff object structure, implemented too early in the project, makes the code unable to be adapted to the drastic changes in the specifications (aka agile).
So I consider as procrastination the activity of defining "layers" or redundant data structures either early in the project or when not specifically required.
Technically, JSP are all converted to Servlets during runtime.
JSP was initially created for the purpose of the decoupling the business logic and the design logic, following the MVC pattern. So JSP is technically all Java code during runtime.
But to answer the question, tag libraries are usually used for applying logic (removing Java code) to JSP pages.
How can I avoid Java code in JSP files?
You can use tab library tags like JSTL in addition to Expression Language (EL). But EL does not work well with JSP. So it's is probably better to drop JSP completely and use Facelets.
Facelets is the first non JSP page declaration language designed for JSF (Java Server Faces) which provided a simpler and more powerful programming model to JSF developers as compare to JSP. It resolves different issues occurs in JSP for web applications development.
Source
If we use the following things in a Java web application, Java code can be eliminated from the foreground of the JSP file.
Use the MVC architecture for a web application
Use JSP Tags
a. Standard Tags
b. Custom Tags
Expression Language
Using Scriptlets is a very old way and not recommended. If you want directly output something in your JSP pages, just use Expression Language (EL) along with JSTL.
There are also other options, such as using a templating engine such as Velocity, Freemarker, Thymeleaf, etc. But using plain JSP with EL and JSTL serves my purpose most of the time and it also seems the simplest for a beginner.
Also, take note that it is not a best practice to do business logic in the view layer. You should perform your business logic in the service layer,
and pass the output result to your views through a controller.
Use a Backbone.js or AngularJS-like JavaScript framework for UI design
and fetch the data using a REST API. This will remove the Java dependency from the UI completely.
Nothing of that is used anymore, my friend. My advice is to decouple the view (CSS, HTML, JavaScript, etc.) from the server.
In my case, I do my systems handling the view with Angular and any data needed is brought from the server using REST services.
Believe me, this will change the way you design.
JSP 2.0 has a feature called "Tag Files", and you can write tags without external Java code and tld. You need to create a .tag file and put it in WEB-INF\tags. You can even create a directory structure to package your tags.
For example:
/WEB-INF/tags/html/label.tag
<%#tag description="Rensders a label with required css class" pageEncoding="UTF-8"%>
<%#attribute name="name" required="true" description="The label"%>
<label class="control-label control-default" id="${name}Label">${name}</label>
Use it like
<%# taglib prefix="h" tagdir="/WEB-INF/tags/html"%>
<h:label name="customer name" />
Also, you can read the tag body easily:
/WEB-INF/tags/html/bold.tag
<%#tag description="Bold tag" pageEncoding="UTF-8"%>
<b>
<jsp:doBody/>
</b>
Use it:
<%# taglib prefix="h" tagdir="/WEB-INF/tags/bold"%>
<h:bold>Make me bold</h:bold>
The samples are very simple, but you can do lots of complicated tasks here. Please consider you can use other tags (for example: JSTL which has controlling tags like if/forEcah/chosen text manipulation like format/contains/uppercase or even SQL tags select/update), pass all kind parameters, for example Hashmap, access session, request, ... in your tag file too.
Tag File are so easy developed as you did not need to restart the server when changing them, like JSP files. This makes them easy for development.
Even if you use a framework like Struts 2, which have lots of good tags, you may find that having your own tags can reduce your code a lot. You can pass your tag parameters to struts and this way customize your framework tag.
You can use tags not only to avoid Java, but also minimize your HTML codes. I myself try to review HTML code and build tags a lot as soon as I see code duplicates start in my pages.
(Even if you end up using Java in your JSP code, which I hope not, you can encapsulate that code in a tag.)
Make your values and parameters inside your servlet classes
Fetch those values and parameters within your JSP using JSTL/Taglib
The good thing about this approach is that your code is also HTML like
code!
A lot of the answers here go the "use a framework" route. There's zero wrong with that. However I don't think it really answers your question, because frameworks may or may not use JSPs, nor are they designed in any way with removing java use in JSPs as a primary goal.
The only good answer to your question "how do I avoid using Java in a JSP" is: you can't. That's what JSPs are for - using Java to render HTML with dynamic data/logic.
The follow up question might be, how much java should I use in my JSPs. Before we answer that question, you should also ponder, "do I need to use JSPs to build web content using Java?" The answer to that last one is, no. There are many alternatives to JSPs for developing web facing applications using Java. Struts for example does not force you to use JSPs - don't get me wrong, you can use them and many implementations do, but you don't absolutely have to. Struts doesn't even force you to use any HTML. A JSP doesn't either, but let's be honest, a JSP producing no HTML is kinda weird. Servlets, famously, allow you to serve any kind of content you like over HTTP dynamically. They are the primary tech behind pretty much everything java web - JSPs are just HTML templates for servlets, really.
So the answer to how much java you should put in a JSP is, "as little as possible". I of course have java in my JSPs, but it consists exclusively of tag library definitions, session and client variables, and beans encapsulating server side objects. The <%%> tags in my HTML are almost exclusively property calls or variable expressions. Rare exceptions include ultra-specific calculations pertaining to a single page and unlikely to ever be reused; bugfixes stemming from page-specific issues only applying to one page; last minute concatenations and arithmetic stemming from unusual requirements limited in scope to a single page; and other similar cases. In a code set of 1.5 million lines, 3000 JSPs and 5000 classes, there are maybe 100 instances of such unique snippets. It would have been quite possible to make these changes in classes or tag library definitions, but it would have been inordinately complex due to the specificity of each case, taken longer to write and debug, and taken more time as a result to get to my users. It's a judgement call. But make no mistake, you cannot write JSPs of any meaning with "no java" nor would you want to. The capability is there for a reason.
As many answers says, use JSTL or create your own custom tags. Here is a good explanation about creating custom tags.
By using JSTL tags together with EL expressions, you can avoid this. Put the following things in your JSP page:
<%# page contentType="text/html;charset=UTF-8" language="java" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

Spring and dynamic inclusion of JSP files

I'm starting building web apps in Spring 3 (and in J2EE) in general.
Looking at the petclinic example I've seen that the programmer creates many JSP pieces, like header, includes, footer and then stitches them together using static inclusion. Anyway what I'd like is that I may have a base page, like Base.jsp and be able to include things like this:
<body>
<jsp:include page="${subpage}"></jsp:include>
</body>
the reason is that I'd like a main page, then being able to put in the ModelAndView returned by the controller which parts of the pages display in each situation (with the data attached to it). This works, but it gives no errors in case ${subpage} is not found, the jsp name is wrong or missing. I'd like more error checking...
Is this the best and recommended way to do this? And if this seems a good idea for what I've in mind, what's the correct way of doing it?
You might want to use Apache Tiles 2 integration for managing your JSP files. Spring has good integration support Apache Tiles. It also shows if there's an error in your page. I've put an example of it at http://krams915.blogspot.com/2010/12/spring-mvc-3-tiles-2-integration.html
It appears you have additional quotes in your subpage. Get rid of them. For example:
<c:set var="subpage" value="/jsp/index.jsp" />
If you have to set it in a controller or servlet - just use request.setAttribute("subpage", "/jsp/index.jsp")
For error checking you can use:
<c:catch var="myException">
<c:import url="${subpage}" />
</c:catch>
and later you can check it with:
<c:if test="${myException != null}">
...
</c:if>
Take a look at Sitemesh (http://www.opensymphony.com/sitemesh). It is a servlet filter-based page layout system that is easy to use. I have done a number of projects using it with Spring MVC and it worked very well.

Two pass JSP page rendering

Suppose an example. I have following interface:
public interface DataSource<T> {
Future<T> fetch();
}
This datasource can do asynchronous data fetching. And we have following tag for using datasource in JSP:
<html>
<d:fetch from="${orderDS}" var="orders">
<c:foreach in="${orders}" var="order">
<div class="order">
<c:out value="${order.title}" />
</div>
</c:foreach>
</d:fetch>
</html>
So, what I want? I want JSP rendering engine to call my custom tag (FetchTag in this example) twice. On first call FetchTag will do DataSource.fetch() call and save Future locally as a object field. On second call FetchTag do Future.get() call and will be blocked until data becomes available.
Is there any way to do such a thing?
I think a better design would not try to alter JSP rendering. Put all that database code on the server side, where it belongs, and use an AJAX call to get that data from a server-side component.
In general, I've found that embedding stuff in custom tag libraries is a bad idea. JSTL and/or Spring tag libraries are all that I need. If I feel like my UI needs to do more, I'm thinking about it incorrectly.
For JS disabled clients, I'd just make them do the round trip for the data and not try to do it in the background. Give them a choice: wait or turn on JS.

Use AJAX instead of TagLib?

I was thinking about the idea of using Ajax instead of TagLib. The most elegant way would be: Using Java Annotation.
The idea is, designers or anybody can make the HTML without any taglib ,just using the "standard" HTML tags with id or name, and call the Javascript. That way any WYSIWYG can be used, developer don't have to care about HTML format or the way it's designed.
In many (at least open-source) WYSIWYG don't show the taglibs in that final result (or have a template of it), so it's hard to "preview". Other reason is, developer should know Java and HTML/TagLibs should not be a must-have, since we got CSS and AJAX.
It should work just like that:
MyClass.java:
import ...
// Use the ResourceBundle resource[.{Locale}].properties
#Jay2JI18n(resourceBundle="org.format.resource",name="MyClassForm")
public class MyClass {
private Integer age;
private String name
private Date dob;
private salary;
#Jay2JLabel(resource="label.name")
#Jay2JMaxLength(value=50,required=true,)
#Jay2JException(resource="exception.message")
public String getName() {
...
}
public void setName(String name) {
if ( name.trim().equal("") ) {
throw new Exception("Name is required");
}
}
/* Getter and setter for age */
...
#Jay2JLabel(message="Salary")
#Jay2JFormat(format="##,###.00",language="en")
#Jay2JFormat(format="##.###,00",language="pt_BR")
// or you could use that to access a property of the ResourceBundle
//#Jay2I18nResource(resource="money.format")
public Date getSalary() {
...
}
/* Setter for salary and getter/setter for the rest */
...
}
Page.html:
<html>
<head>
<SCRIPT>
</SCRIPT>
</head>
<body>
<form onload="Jay2J.formalize(this)">
</form>
</body>
</html>
of it can be a HTML with the fields filled;
PageWithFields.html:
<html>
<head>
<SCRIPT>
</SCRIPT>
</head>
<body>
<form action="myfavoritewaytopostthis" onsubmit="return Jay2J.validate(this)" onload="Jay2J.formalizeExistField(this)">
<label>Name</label><input type="text" name="name" id="name" />
<label>DOB</label><input type="text" name="dateOfBirth" id="dob" />
<label>Salary</label><input type="text" name="salary" id="salary" />
<input type="submit" />
</form>
</body>
</html>
That way the Annotation (no XML, it's like HTML in the way that it's only another file modify and XML is not Java) will define how the HTML will be treated. That way developer can stop developing in HTML and use just JAVA (or JavaScript), do you think that's a valid idea?
When i see your topic title i thought:
You cant use Ajax in stead of a taglib. AJAX is javascript on the client and the taglib is java code on the server.
After reading your post i thought, ah he whats to do what [link text][1] does
But then not entrily the same.
[1]: http://code.google.com/webtoolkit/ GWT
First impression is ... yuck, someone who picks this up will have no idea what they're looking at without learning your (new, different, non-standard) way of doing things. You could do something similar by implementing a tag that takes a bean (value object) and maybe does some minor reflection/annotation inspection to emit the proper html, and you'll save yourself a lot of heartache down the line.
Make your value objects implement a simple interface that your tag will use to extract and format the html, and you can probably get 80-90% of where you're trying to go with 1/2 the work or less.
First impression was, WTF. After reading further, I get a impression that you are trying to address the 'separation of concerns'problem in a different way. Some observations on your approach.
Requires client side scripting to be enabled and hence fails accessibility guide lines.
Reinventing the wheel: Many web frameworks like Tapestry, Wicket try to address these issues and have done a commendable work.
On your comment on binding Java to HTML, the code example doesn't convey the idea very clearly. formalize() seems to create the UI, that implies you have UI (HTML) coded into java (Bad Idea? probably not NakedObjects attempts to you domain models for UI, probably yes if one were to write a page specific code)
validate() is invoked on onSubmit(), Why would I want it to be processed asynchronously!! That aside, using obstrusive java script is way out of fashion (seperation of concerns again)
Your argument on taglibs preventing WYSIWIG, though justifiable, is not entirely valid. Tags cannot be used to compose other tags, each tag is a unique entity that either deals with behaviour or emits some html code. Your argument is valid for the second case. However, if I understand your formalize() correctly, you are doing the same!
Nice to hear some new ideas and Welcome to SO. Also, please use the edit question option until you earn enough reputation to add comments. Adding answers is not the right way!
This idea has some merit, if I understand it correctly.
You could use AOP to modify a servlet that would actually be called for the page. The servlet would then return the html, using the annotations.
This way the programmers don't see the html generation, and if you have a standard javascript library for it, then it may work.
But, just because it works doesn't mean that you should do it.
As was mentioned, there are many frameworks out there that can hide the javascript from programmers, such as JSF, which is basically taglibs and a different navigation scheme.
I remember using the beehive project to do something similar, it was annotation driven so I could basically do everything in java and it generated the javascript, years ago. :)

Categories