One of the fundamental goals of JSP pages is to decouple business logic from
presentation; often JSP page developers tend to use a lot of messy scriptlet
code. This approach not only clutters the page, but also leads to maintenance
nightmare. The EL (Expression Language) can be effective to keep scriptlet code
away from JSP pages. An Expression Language makes it possible to easily access
application data stored in JavaBeans components without any scriptlet code. It
provides a way to simplify Expressions in JSP. It is a simple language used for
accessing implicit objects and Java classes, and for manipulating collections in
an elegant manner. EL provides the facility to use run-time expressions outside
JSP scripting elements.
|
JSP standard actions
JSP standard actions are powerful. They can avoid lot of boilerplate scriptlet
code and ease JSP code development. JSP standard actions are great time-savers
and help in JSP view generation. You can leverage from standard actions like
and getting bean properties . For instance, you can develop loosely-coupled
business objects as POJOs and call them from inside your JSP pages without any
scripting. This not only relieves you from writing scriptlet code but also helps
in maintenance and keeping the code readable. Consider the following code
snippet, where a POJO bean is instantiated and its properties are set in one
simple custom action tag.
The JSP Expression Language author can access a bean using a simple syntax |
Go back to scripting
Although JSP standard actions relieve you from boilerplate scriptlet code
writing, but often you would land in situations where you will have no choice
for messing up your JSP page with the scriptlet code. For instance, consider a
situation where an Employee HAS-A Manager property called manager, which
represents an object other than the primitive type or String.
In order to extract the manager information without standard action, you
would need to use scriptlet code as shown here.
<%= ((com.pcquest.hrms.Employee)
request.getParameter(“employee”)).getManager().getName()%>
If you still use JSP standard action, you would get the hashcode, which
represents the Manager object on JVM heap and has no meaning for the client:
The
attribute. There's no capability for nested properties, where you want a
property of a property, rather than a property of attributes.
EL to the rescue
EL provides the ability to use run-time expressions outside JSP scripting
elements. Scripting elements are the elements in a page that can be used to
embed Java code in the JSP file. They are commonly used for object manipulation
and performing computation that affects the generated content. JSP 2.0 adds EL
Expressions as a scripting element. Scripting elements have three subforms-
Declaration, Scriptlets and Expressions. Let's look at these three subforms in
code.
<%! int i = 1; %> <% -- Declaration
--%>
<% for (int i =0; i < 10; i++) { %> <% -- Scriptlets --%>
<%= request.getParameter(“fName”)%> <% -- Expression --%>
With the addition of EL to the JSP toolkit, the above code can be written
using a simpler syntax yet achieving the same results as the JSP elements above.
Another advantage of EL Expressions is its use in scriptless JSP pages that do
not permit the usage of any of the above scripting element subforms. However,
JSP pages can be written without using any of the three scripting element
subforms, and that the choice of whether a JSP page should be scriptless, is
entirely based on the requirements and needs of your application.
EL syntax
The JSP Expression Language allows a page author to access a bean using a simple
syntax such as ${first.second}. Some valid EL syntax include ${pageContext.request.method},
which would return the HTTP method name used by the client request. Another
valid EL expression is ${pageContext.exception} for JSP pages that have the
isErrorPage property set as true.
EL functions
The JSP Expression Language allows you to define a function that can be invoked
in an expression. Functions are defined using the same mechanisms as custom
tags. To use EL functions, you need three artifacts- a JSP page with a taglib
directive, a valid tag library descriptor (TLD) file, which defines the function's
signature and the implementation class. EL functions are public static functions
defined in public classes. The following code snippet shows how to use a taglib
directive in a JSP page.
<%@ taglib prefix=”caldisc” uri=”utilRunner”
%>
An EL function needs to be defined in the deployment descriptor web.xml file.
This information helps map a public class with a public static function that can
be called from inside a JSP page. The code snippet given below shows how to code
for an EL function in the deployment descriptor file.
com.pcquest.ecom.ProductDiscount
double computeDiscount(double)
The TLD file is placed inside the private WEB-INF directory. Note that with
Java EE 5, you no longer need an entry in the deployment descriptor, the
container at runtime finds the required TLD file with the help of the URI used.
Forcing scriptfree code
If you want a clear separation between your presentation and business logic,
then you also have the choice to force the page to go scriptless. By enforcing
scriptless pages, the dynamic behavior of JSP pages must be provided through
other elements such as JavaBeans, EL Expressions, Custom actions and standard
tag libraries.
You can force the developers working on a common project to agree to a
standard protocol and avoid using any scriptlet code in their JSP pages. This
helps in a mutual compatibility across different modules and simplifies
development cycle. You can make it invalid for a JSP view to have scripting
elements by putting a
Conclusion
Inspired by Java Script, EL can remove scriptlet code from your JSP views. EL
gracefully treats null values and performs more data-type conversions
automatically. These features are important for a web application, where the
input is mostly in the form of request parameters. Further, with EL, we can use
Lists, Maps, JavaBeans and scoped attributes without touching scriptlet. EL
comes in handy when you want a clear distinction of your presentation from
business logic and helps in easy maintenance and improves the readability of
code.