EL stands for “Expression Language”, and it became officially part of the spec beginning with JSP 2.0 spec. EL is nearly always a much simpler way to do some of the things you’d normally do with scriptlets and expressions.
Of course right now you’re thinking, “But if I want my JSP to use custom methods, how can I declare and write those methods if I can’t use Java?”
Ahhhh... writing the actual functionality (method code) is not the purpose of EL. The purpose of EL is to offer a simpler way to invoke Java code—but the code itself belongs somewhere else.
That means in a regular old Java class that’s either a JavaBean, a class with static methods, or something called a Tag Handler.
In other words, you don’t write method code into your JSP when you’re following today’s Best Practices. You write the Java method somewhere else, and call it using EL.
Oh if only there were a way in a JSP to use simple tags that cause Java methods to run, without having to put actual Java code into the page.
Sneak peek at EL
The entire next chapter is on EL, so we won’t go into details here.
The only reason we’re covering it is because it’s yet another kind of element (with its own syntax) that goes in a JSP, and the exam objectives for this chapter include recognizing everything that can go into a JSP.
Please contact: ${applicationScope.mail}
This EL expression:
Please contact: <%= application.getAttribute(“mail”) %>
Is the same as this Java expression:
An EL expression ALWAYS looks like this: ${something}
In other words, the expression is ALWAYS enclosed in curly braces, and prefi xed with a dollar ($) sign.
there are no
Dumb Questions
Q: Not to be all negative, but I’m not sure I see an earth-shattering diff erence between the EL and the Java expression. Sure, it’s a little shorter, but is that worth a whole new scripting language and JSP coding approach?
A: You SO haven’t seen the full benefit of EL yet. The differences will become obvious in the next chapter when we dive in. But you must remember that to a Java programmer, EL is NOT neccessarily a dramatic development advantage. In fact, to a Java programmer it simply means
“one more thing (with its own syntax and everything) to learn, when, hey, I already KNOW Java...”
But it’s not always about you. EL is much easier for a non-Java programmer to learn and get up to speed in. And for a Java programmer, it is still much easier to maintain a scriptless page.
Yes, it’s still something to learn. It doesn’t let web page designers completely off the hook, but you’ll soon see that it’s more intuitive and natural for a web designer to use EL. For now, in this chapter, you simply need to be able to recognize EL when you see it. And don’t worry at this fi rst look at EL
And just HOW do you expect me to get my programmers to stop using scripting elements in their
JSPs?
Easy—you can put an element in the DD that
disables all scripting elements!
Using <scripting-invalid>
It’s simple—you can make it invalid for a JSP to have scripting elements (scriptlets, Java expressions, or declarations) by putting a <scripting-invalid> tag in the DD:
<web-app ...>
... <jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>
true
</scripting-invalid>
</jsp-property-group>
</jsp-config>
</web-app> ...
This disables scr ipting elements for ALL JSPs in the app
(because we used the wildcard
*.jsp as the URL pa ttern.)
Watch out—you might have seen other books or articles show a page directive that disables scripting. In a draft version of the 2.0 spec, there was a page directive attribute:
<%@ page isScriptingEnabled=”false” %>
but it was removed from the final spec!!
The only way to invalidate scripting now is
This does not work!
The isScriptingEnabled attribute is no longer in the JSP spec!
You can choose to ignore EL
Yes, EL is a good thing that’s going to save the world as we know it. But sometimes you might want to disable it. Why?
Think back to when the assert keyword was added to the Java language with version 1.4. Suddenly the formerly unreserved and perfectly legal identifier “assert” meant something to the compiler. So if you had, say, a variable named assert, you were screwed. Except that J2SE version 1.4 came with assertions disabled by default. If you knew you were writing (or recompiling) code that didn’t use assert as an identifier, then you could choose to enable assertions.
So it’s kind of the same thing with disabling EL—if you happened to have template text (plain old HTML or text) in your JSP that included something that looked like EL (${something}), you’d be in Big Trouble if you couldn’t tell the Container to just ignore anything that appears to be EL and instead treat it like any other unprocessed text. Except there’s one big difference between EL and assertions:
El is enabled by default!
If you want EL-looking things in your JSP to be ignored, you have to say so explicitly, either through a page directive or a DD element.
<web-app ...>
... <jsp-confi g>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<el-ignored>
true
</el-ignored>
</jsp-property-group>
</jsp-confi g>
</web-app> ...
Putting <el-ignored> in the DD
Using the isELIgnored page directive attribute
<%@ page isELIgnored=”true” %>
If you want EL-looking things in your JSP to be ignored, you have to say so
If there’s a confl ict between the
<el-ignored> setting in the DD and the isELIgnored page directive attri- bute, the directive always wins! That lets you specify the default behavior in the DD, but override it for a specifi c page using a page directive.
The page directive takes priority over the DD setting!
<%@ page isELIgnored=”true” %> But no, one would be wattribute would be, oh, mThe DD tag is <el-ignoreasonably think that thred>, so one might e page directive aybe elIgnored?
Watch out for the naming inconsistency!
ignoring EL
But wait... there’s still another JSP element we haven’t seen: actions
So far, you’ve seen five different types of elements that can appear in a JSP:
scriptlets, directives, declarations, Java expressions, and EL expressions.
But we haven’t seen actions. They come in two flavors: standard and...not.
<jsp:include page=”wickedFooter.jsp” />
Standard Action:
<c:set var=”rate” value=”32” />
Other Action:
Although that’s misleading, because there are some actions that aren’t considered standard actions, but which are still part of a now-standard library.
In other words, you’ll later learn that some of the non-standard (the objectives refer to them as custom) actions are... standard, but yet they still aren’t considered “standard actions”. Yes, that’s right—they’re standardized non-standard custom actions. Doesn’t that just clear it right up for you?
In a later chapter when we get to “using tags”, we’ll have a slightly richer vocabulary with which to talk about this in more detail, so relax. For now, all we care about is recognizing an action when you see it in a JSP!
Sharpen your pencil
Look at the syntax for an action, and compare it to the syntax for the other kinds of JSP elements. Then answer this:
1) What are the differences between an action element and a scriptlet?
2) How will you recognize an action when you see it?
For now, don’t worry about what these do or how they w ork, just recognize an ac tion when you see the syntax in a JSP. La ter, we’ll go into the details.
1
Think about what happens when each of these settings (or combination of settings) occurs. You’ll see the answers when you turn the page, so do this one NOW.
Evaluation Matrix
unspecified unspecified
false unspecified
true unspecified
false false
false true
true false
DD configuration
<el-ignored> page directive
isELIgnored evaluated ignored Place a checkmark in the evaluated column if the settings would cause the EL expressions to be evaluated, OR place a checkmark in the ignored column if EL will be treated like other template text.
No row will have two checkmarks, of course.
EL Evaluation
2
unspecified true
DD configuration
<scripting-invalid> evaluated error
Scripting validity
Exercise
evaluation exercise
Place a checkmark in the evaluated column if the settings would cause the scripting expressions to be evaluated, OR place a checkmark in the error column if scripting will cause a translation error.
JSP Element Magnets
Match the JSP element with its label by placing the JSP snippet in the box with the label representing that element type. Remember, you’ll have Drag and Drop questions on the real exam similar to this exercise, so don’t skip it!
directive
declaration
EL expression
scriptlet
expression
<%@ page import=”java.util.*” %>
<%! int y = 3; %>
email: ${applicationScope.mail}
<%! int y = 3; %>
<%! int y = 3; %>
<% Float one = new Float(42.5); %>
<%= pageContext.getAttribute(“foo”) %>
<%= pageContext.getAttribute(“foo”) %>
<%= pageContext.getAttribute(“foo”) %>
<jsp:include page=”foo.html” />
JSP element type JSP snippet
Drag these ov er and drop them ont o the
matching l abel.
public fi nal class BasicCounter_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent {
public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException { ...
...
} }
JSP Element Magnets: the Sequel
You know what they’re called, but do you remember where they go in the generated servlet? Of course you do. But this is just a little reinforcement/practice before we move on to a different chapter and topic.
(Put the element in the box corresponding to where that element’s generated code will go in the servlet class fi le. Note that the magnet itself does not represent the ACTUAL code that will be generated.
<%= request.getAttribute(“foo”) %>
JSP elements exercise
The order of these three magnets does not matter.
1
Evaluation Matrix ANSWERS
unspecified unspecified
false unspecified
true unspecified
false false
false true
true false
DD configuration
<el-ignored> page directive
isELIgnored evaluated ignored
EL Evaluation
2
unspecified true false
DD configuration
<scripting-invalid> evaluated error
Scripting validity Exercise
JSP Element Magnets
ANSWERS
directive
declaration
EL expression
scriptlet
expression directive
<%@ page import=”java.util.*” %>
declaration
<%! int y = 3; %>
EL expression
email: ${applicationScope.mail}
scriptlet
<% Float one = new Float(42.5); %>
expression
<%= pageContext.getAttribute(“foo”) %>
Of course the word “expression” is over- loaded for JSP elements. If you see the word “expression” or “scripting expression”
it means the same thing—an expression using Java language syntax:
<%= foo.getName() %>
The only time the word “expression” refers to EL is if you specifi cally see “EL” in the descriptions or label! So, always assume that the default for the word “expression”
is “scripting/Java expression”, not EL.
The word “expression”
by itself means
“scripting expression”
NOT “EL expression”.
JSP elements answers
public fi nal class BasicCounter_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent {
public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException { ...
...
} }
JSP Element Magnets: the Sequel
ANSWERS
<%= request.getAttribute(“foo”) %>
<%@ page import=”java.util.*” %>
<%! int y = 3; %>
<% Float one = new Float(42.5); %>
email: ${applicationScope.mail}
A page directive with an import attr ibute turns into a Java import statement.
Declarations are for MEMBER declarations, so they go inside the cl ass and outside any method.
Expressions turn into print() statements in the service method.
Scriptlets go inside the service method.
EL expressions go inside the service method.
NOTE: remember that the JSP code doesn’t ac tually GO into the servlet like this... it’s all translated into Jav a language code. This exercise is jus t to show you in what part of the genera ted class these elements GO, but w e’re
not showing you the actual genera ted code the elements are transla ted into.
rom <%! int y = 3; %> to just int y = 3;
(Note: the order of these three things doesn’t matter.)
Given this DD element:
47. <jsp-property-group>
48. <url-pattern>*.jsp</url-pattern>
49. <el-ignored>true</el-ignored>
50. </jsp-property-group>
What does the element accomplish? (Choose all that apply.)
A. All files with the specified extension mapping should be treated by the JSP container as well-formed XML files.
B. All files with the specified extension mapping should have any Expression Language code evaluated by the JSP container.
C. By default, all files with the specified extension mapping should NOT have any Expression Language code evaluated by the JSP container.
D. Nothing, this tag is NOT understood by the container.
E. Although this tag is legal, it is redundant, because the container behaves this way by default.
q q q q q
1
Mock Exam Chapter 7
Which directives specify an HTTP response that will be of type “image/svg”?
(Choose all that apply.)
A. <%@ page type=”image/svg” %>
B. <%@ page mimeType=”image/svg” %>
C. <%@ page language=”image/svg” %>
D. <%@ page contentType=”image/svg” %>
E. <%@ page pageEncoding=”image/svg” %>
q q q q q
2
mock exam
Given this JSP:
1. <%@ page import=”java.util.*” %>
2. <html><body> The people who like 3. <%= request.getParameter(“hobby”) %>