Introduction to JSP Part 2 (Server-Side Programming using Java Server Pages) cs236607
Java Beans in JSP cs236607
Motivation Software components (e.g. objects, data structures, primitives) are extensively used in Web applications For example: Service local variables Attributes forwarded in requests Session attributes, such as user information Application attributes, such as access counters See tutorial at http://java.sun.com/docs/books/tutorial/javabeans/ cs236607
Motivation Standard actions are used to manipulate components: declaration, reading from the suitable context, setting of new values (according to input parameters), storing inside the suitable context, etc. Java Beans provide a specification for automatic handling and manipulation of software components in JSP (and other technologies...) cs236607
Java Beans: The Idea Java Beans are simply objects of classes that follow some (natural) coding convention: An empty constructor A readable property has a matching getter A writable property has a matching setter Use JSP actions to access and manipulate the bean, and special action attributes to specify the properties of the bean, e.g., its scope JSP programmers do not wish to write cumbersome code or class files cs236607
Example 1: Access Counter In the following example, we use a Bean to maintain an access counter for requests to the pages cs236607
Counter Bean package myUtils; public class CounterBean { A Bean is a concept and therefore there’s no need to extend any class or implement any interface! (though it would’ve been very Java-ish to create an empty interface “Bean”) Counter Bean Bean must reside in a package package myUtils; public class CounterBean { private int counter; public CounterBean() { counter = 0; } public int getCounter() { return counter; } public void setCounter(int i) { counter = i; } public void increment() { ++counter; } } A Bean is created by an empty constructor Counter setter and getter Other methods can be implemented as well CounterBean.java cs236607
<jsp:useBean id="accessCounter" <html> <head><title>Bean Example</title></head><body> <jsp:useBean id="accessCounter" class=“myUtils.CounterBean" scope="application"/> <% accessCounter.increment(); %> <h1> Welcome to Page A</h1> <h2>Accesses to this application: <jsp:getProperty name="accessCounter" property="counter"/> </h2> <a href="pageB.jsp">Page B</a></body> </html> The default scope is page You could also use the type attribute in order to instantiate a data type which is either superclass of class or an interface that class implements An instance named according to the given id is either found in the relevant scope or is created Invokes getCounter() pageA.jsp cs236607
<jsp:useBean id="accessCounter" <html> <head><title>Bean Example</title></head><body> <jsp:useBean id="accessCounter" class=“myUtils.CounterBean" scope="application"/> <% accessCounter.increment(); %> <h1> Welcome to Page B</h1> <h2>Accesses to this application: <jsp:getProperty name="accessCounter" property="counter"/> </h2> <a href="pageA.jsp">Page A</a></body> </html> Since an instance named according to the given id can be found in the application scope, no instantiation takes place pageB.jsp A very similar JSP cs236607
Part of the Generated Servlet The instance is created and kept in the application’s scope as required. Note however that accessing this instance is out of the synchronized scope myUtils.CounterBean accessCounter = null; synchronized (application) { accessCounter = (myUtils.CounterBean) _jspx_page_context.getAttribute("accessCounter", PageContext.APPLICATION_SCOPE); if (accessCounter == null) { accessCounter = new myUtils.CounterBean(); _jspx_page_context.setAttribute("accessCounter", accessCounter, PageContext.APPLICATION_SCOPE); } Similar effect to getServletContext().getAttribute() Similar effect to getServletContext().setAttribute() cs236607
Example 2: Session Data In the following example, we use a Bean in order to keep a user's details throughout the session cs236607
public class UserInfoBean { private String firstName; package myUtils; public class UserInfoBean { private String firstName; private String lastName; public UserInfoBean() { firstName = lastName = null;} public String getFirstName() {return firstName;} public String getLastName() {return lastName;} public void setFirstName(String string) {firstName = string;} public void setLastName(String string) {lastName = string;} } UserInfoBean.java cs236607
<head><title>Information Form</title></head> <html> <head><title>Information Form</title></head> <body> <h1>Fill in your details:</h1> <form action="infoA.jsp" method="get"><p> Your First Name: <input type="text" name="firstName" /> <br/> Your Last Name: <input type="text" name="lastName" /><br/> <input type="submit" /></p> </form> </body></html> infoForm.html cs236607
<jsp:setProperty name="userInfo" property="*"/> <jsp:useBean id="userInfo" class=“myUtils.UserInfoBean" scope="session"/> <jsp:setProperty name="userInfo" property="*"/> <html> <head><title>Page A</title></head><body> <h1>Hello <jsp:getProperty name="userInfo" property="firstName"/> <jsp:getProperty name="userInfo" property="lastName"/>, </h1> <h1>Have a nice session!</h1> <h2> <a href="infoB.jsp">User Info B</a></h2> </body></html> The String values are converted to the right bean’s property types.. Match all the request parameters to corresponding properties. You could match parameters to properties explicitly using property=… param=… You can also set properties with explicit values using property=… value=… infoA.jsp cs236607
<jsp:setProperty name="userInfo" property="*"/> <jsp:useBean id="userInfo" class=“myUtils.UserInfoBean" scope="session"/> <jsp:setProperty name="userInfo" property="*"/> <html> <head><title>Page B</title></head><body> <h1>Hello <jsp:getProperty name="userInfo" property="firstName"/> <jsp:getProperty name="userInfo" property="lastName"/>, </h1> <h1>Have a nice session!</h1> <h2> <a href="infoA.jsp">User Info A</a></h2> </body></html> This time the request has no parameters so no bean properties are set A very similar JSP infoB.jsp cs236607
Advantages of Java Beans Easy and standard management of data Automatic management of bean sharing and lots more Good programming style Allow standard but not direct access to members You can add code to the setters and getters (e.g. constraint checks) without changing the client code You can change the internal representation of the data without changing the client code Increase of separation between business logic (written by programmers) and HTML (written by GUI artists) cs236607
Custom JSP Tags cs236607
Custom JSP Tags JSP code may use custom tags – tags that are defined and implemented by the programmer The programmer defines how each of the custom tags is translated into Java code There are two methods to define custom tags: Tag libraries - used in old versions of JSP Tag files - much simpler, introduced in JSP 2.0 cs236607
Tag Libraries A tag library consists of: Tag handlers - Java classes that define how each of the new tags is translated into Java code A TLD (Tag Library Descriptor) file, which is an XML file that defines the structure and the implementing class of each tag (see a tutorial at http://java.sun.com/products/jsp/tutorial/TagLibrariesTOC.html) cs236607
A Simple TagLib Example Goal: <mytag:date/> We must use a package (not necessarily named like your application) since this is a helper class which is imported form the JSP’s generated Servlet that is placed within a named package The java file is placed in webapps/myapp/WEB-INF/src/my/ The class file is placed in webapps/myapp/WEB-INF/classes/my/ package my; import javax.servlet.jsp.JspException; import javax.servlet.jsp.tagext.SimpleTagSupport; import java.io.IOException; public class DateTag extends SimpleTagSupport { public void doTag() throws JspException, IOException { getJspContext().getOut().print(new java.util.Date()); } DateTag.java Base class of tags which don’t handle the body or the attributes Using the JSP-context, You can also acquire other implicit objects by calling getSession(), getRequest() etc… cs236607
<name>date</name> <taglib> <tlib-version>1.0</tlib-version><jsp-version>2.0</jsp-version> <tag> <name>date</name> <tagclass>my.DateTag</tagclass> <body-content>empty</body-content> </tag> </taglib> Set this value that indicates your tag library version Name of the tag Tag’s class file in /myapp/WEB-INF/classes/my/ This defined tag contains no body The prefix for this tag must appear before the tag itself (looks like a namespace). The Prefix can’t be empty You can add here more tags… my-taglib.tld <%@ taglib prefix=“mytag" uri="/WEB-INF/tags/my-taglib.tld" %> <html><body> <h1>Hello. The time is: <mytag:date/></h1> </body></html> As you can see from the path, the taglib is specifically defined to the current application context. taglibuse.jsp The path could be a URL. If you choose to use a local path, it must begin with /WEB-INF/tags/ cs236607
Taglib with Attributes package my; import javax.servlet.jsp.JspException; import javax.servlet.jsp.tagext.TagSupport; import java.io.IOException; public class DateTag2 extends TagSupport { private boolean isLongFormat = false; public void setIsLongFormat(boolean b) { isLongFormat = b; } public boolean getIsLongFormat() { return isLongFormat; { Base class of tags which do handle attributes In our example the attribute is defined as not required so it must have a default value The setter/getter methods should be named after the attribute (i.e. “get” + capital (<attribute>)) This member’s name should be identical to the attribute’s. Attribute’s setter method Attribute’s getter method DateTag2.java cs236607
public int doStartTag() throws JspException { try { if (isLongFormat) { pageContext.getOut().print(new java.util.Date().getTime()); } else { pageContext.getOut().print(new java.util.Date()); } } catch (Exception e) { throw new JspException("DateTag: " + e.getMessage()); } return SKIP_BODY; public int doEndTag() { return EVAL_PAGE; Invoked when the generated Servlet starts processing the “start tag” Prints the date according to the isLongFormat attribute Signals the generated Servlet there’s no body within the tag to process Invoked when the generated Servlet starts processing the “end tag” Signals the generated Servlet to continue executing the generated Servlet code cs236607
my-taglib2.tld taglibuse2.jsp <tag> <name>date2</name> <tagclass>my.DateTag2</tagclass> <body-content>empty</body-content> <attribute> <name>isLongFormat</name> <required>false</required> </attribute> </tag> Same as before, only with different names for the tagclass You can put several blocks one after another The attribute is “not required” so you have to define a default value in DateTag2.java my-taglib2.tld <%@ taglib prefix=“mytag" uri="/WEB-INF/tags/my-taglib2.tld" %> <html><body> <h1>Hello.</h1> <h2>The time is: <mytag:date2/></h2> <h2>Milliseconds since the epoch : <mytag:date2 isLongFormat="true" /></h2> </body></html> Uses default attribute value Uses a given attribute value taglibuse2.jsp cs236607
How does it work? taglibuse2_jsp.java taglibuse2.jsp JspContext Create the JspContext When the translation engine first encounters <mytag:date2> it creates a new instance of DateTag2 (so we needn’t worry about concurrency issues) and passes it the JspContext reference JspContext JSP to Java Servlet translation DateTag2 setIsLongFormat() doStartTag() doEndTag() The attribute value is set using the setter method. The translator actually translated the attribute string value as it appears in the JSP source, to a boolean value as the Java tag class expects it… “Start tag” is reached “End tag” is reached cs236607
Tag Files JSP 2.0 provides an extremely simplified way of defining tags The motivation: JSP programmers prefer not to write cumbersome code or class files The idea: for each custom tag, write a tag file tagName.tag that implements the tag translation using JSP code This way, the programmer can avoid creating tag handlers and TLD files cs236607
The Simplified Example date.tag <%= new java.util.Date() %> <%@ taglib prefix=“mytag" tagdir="/WEB-INF/tags/" %> <html> <body> <h1>Hello. The time is: <mytag:date/></h1> </body> </html> In this new mechanism we use tagdir instead of uri we used in the old taglib implementation taguse.jsp cs236607
The Attributes Example A new directive <%@ attribute name="isLongFormat" required="false" %> <%!private String createDate(String isLong) { if ((isLong == null) || (isLong.equals("false"))) { return new java.util.Date().toString();} else { return new Long(new java.util.Date().getTime()).toString();} } %> <%=createDate(isLongFormat)%> date3.tag Default and isLongFormat=“false” case Private method declaration isLongFormat=“true” case Calls the private method The isLongFormat parameter is identified as the isLongFormat attribute because we used the attribute directive <%@ taglib prefix=“mytag" tagdir="/WEB-INF/tags/" %> <html><body> <h1>Hello.</h1> <h2>The time is: <mytag:date3/></h2> <h2>Milliseconds since the epoch : <mytag:date3 isLongFormat="true" /></h2> </body></html> Default case isLongFormat=“true” cs236607 taguse3.jsp
Other Capabilities of Custom Tags Attributes You can add validation mechanism for the attributes values Tag Body Tag translation may choose to ignore, include or change the tag body cs236607
JSP Expression Language cs236607
JSP Expression Language JSP expression language is a comfortable tool to access useful objects in JSP This language provides shortcuts in a somewhat JavaScript-like syntax An expression in EL is written as ${expr} For example: Hi, ${user}. <em style="${style}">Welcome</em> Note that the EL expression does not violate the XML syntax as opposed to <%= expression %> cs236607
EL Variables JSP EL does not recognize JSP's implicit objects, but rather has its own set Each of these objects maps names to values param, paramValues, header ,headerValues, cookie, initParam, pageScope, requestScope, sessionScope, applicationScope For example, use the param[“x”] or param.x to get the value of the parameter x Map a parameter name to a single value or to multiple values Map a header name to a single value or to multiple values Maps a cookie name to a single value Maps a context initialization parameter name to a single value cs236607
EL Variables (cont) A variable that is not an EL implicit object is looked up at the page, request, session (if valid) and application scopes That is, x is evaluated as the first non-null element obtained by executing pageContext.getAttribute("x"), request.getAttribute("x"), etc. Might be confusing. Make sure you know what you’re accessing! cs236607
Object Properties In JSP EL, Property prop of Object o is referred to as o[prop] Property prop of Object o is evaluated as follows: If o is a Map object, then o.get(prop) is returned If o is a List or an array, then prop is converted into an integer and o.get(prop) or o[prop] is returned Otherwise, treat o “as a bean”, that is: convert p to a string, and return the corresponding getter of o, that is o.getProp() The term o.p is equivalent to o["p"] cs236607
An Example <% response.addCookie(new Cookie(“nameof",“homer")); session.setAttribute(“homepage", new java.net.URL("http://www.simpsons.com")); String[] strs = {"str1","str2"}; session.setAttribute("arr", strs); %> <html><head><title>JSP Expressions</title></head><body> <form method="get" action="el.jsp"> <h2>Write the parameter x: <input name="x" type="text" /> <input type="submit" value="send" /></h2> </form> </body></html> elcall.jsp cs236607
<%@ page isELIgnored="false" %> <html> <head><title>EL Examples</title></head> <h1>Expression-Language Examples</h1> <h2>Parameter <code>x</code>: ${param["x"]} </h2> <h2>Cookie <code>name</code>: ${cookie.nameof.value}</h2> <h2>Header <code>Connection</code>: ${header.Connection} </h2> <h2>Path of session attr. <code>homepage</code>: ${sessionScope.homepage.path}</h2> <h2>Element <code>arr[${param.x}]</code>: ${arr[param.x]} </h2> </body></html> The default value is TRUE ${…} means evaluate the expression inside the {} cookie[“nameof”].getValue() header [“Connection”] sessionScope[“homepage”]. getPath(). You can omit the sessionScope Only the ${param.x} is evaluated el.jsp cs236607 sessionScope[“arr”][param[“x”]
JSP and XML cs236607
Simple XML Production <?xml version="1.0"?> Ordinary XML declarations Ordinary XML declarations Link with XSL stylesheet <?xml version="1.0"?> <!DOCTYPE colors SYSTEM "colors.dtd"> <?xml-stylesheet type="text/xsl" href="colors.xsl"?> <%! static String[] colors = {"red","blue","green"}; %> <%@ page contentType="text/xml" %> <colors> <% for(int i=0; i<3; ++i) { %> <color id="<%=i%>"><%= colors[i] %></color> <% } %> </colors> JSP directive which sets the MIME-type of the result… cs236607
Generated XML <?xml version="1.0"?> <!DOCTYPE colors SYSTEM "colors.dtd"> <?xml-stylesheet type="text/xsl" href="colors.xsl"?> <colors> <color id="0">red </color> <color id="1">blue</color> <color id="2">green</color> </colors> cs236607
JSPX Files (JSP Documents) JSPX files are JSP files that have the extension jspx and have XML syntax JSPX files are also referred to as JSP documents Special JSP tags are used to replace non-XML JSP symbols (<%, <%@, etc.) (Tags and EL can help too!) The default content type of JSPX is text/xml (and not text/html) You can also keep the .jsp suffix and tell the container that a JSP file acts as a JSPX file (and therefore its output is of XML type etc.) cs236607
Advantages/Disadvantages of JSPX Since JSPX documents conform to a legal XML structure you can: Check if the document is well formed XML Validate the document against a DTD Nest and scope namespaces within the document Use all kinds of XML tools (e.g. editors) The main disadvantage is JSPX documents they can grow very long and very (very) cumbersome Much ado about nothing? Sometimes the above “advantages” simple aren’t needed or are of little help cs236607
<%= Expression %> <jsp:expression> Expression </jsp:expression> <% Code %> <jsp:scriptlet> Code </jsp:scriptlet> <%! Declaration %> <jsp:declaration> Declaration </jsp:declaration> An empty element <%@ Directive %> <jsp:directive.type Attribute="value"/> cs236607
Problems on the Way to a Legal XML The XML declaration (<?xml version="1.0"?>) and the DOCTYPE definition are now those of the JSPX file. How do we include the declaration+dtd of the original XML document in the result XML? Solution: use the <jsp:output> tag to explicitly require DOCTYPE and XML declarations (next slide…) How do we generate dynamic attribute values and still keep the document well formed? Solution 1: use <jsp:element> for explicit element construction Solution 2: use an EL expression The following line is an illegal XML opening tag: <color id=“<jsp:expression>i</jsp:expression>“> cs236607
<?xml version=“1.0” ?> <colors xmlns:jsp="http://java.sun.com/JSP/Page"> <jsp:output doctype-root-element="colors" doctype-system="colors.dtd" /> <jsp:output omit-xml-declaration="false"/> <jsp:declaration> static String[] colors = {"red","blue","green"};</jsp:declaration> <jsp:scriptlet><![CDATA[ for(int i=0; i<3; ++i) { ]]></jsp:scriptlet> <jsp:element name="color"> <jsp:attribute name="id"> <jsp:expression>i</jsp:expression> </jsp:attribute> <jsp:expression>colors[i]</jsp:expression> </jsp:element> <jsp:scriptlet>} </jsp:scriptlet> </colors> Namespace of basic JSP elements and Tag libraries.. Root element + DTD of the resulting XML Do not omit the XML declaration of the result CDATA is used because of <. Altenatively: use < The result is equivalent to the original line: <color id="<%=i%>"><%= colors[i] %></color> cs236607
A Few More Problems on the Way Where can we add an XSL declaration? It should be: outside the root element (colors), but also after jsp:output which must be defined after jsp namespace declaration within the colors element… When using the include directive, the JSP might become illegal XML with more than a single root A solution: Use the <jsp:root> element as the document root Does this solve all the problems which might arise when using the include directive? cs236607
<. xml version=“1. 0”. > <jsp:root version="2 <?xml version=“1.0” ?> <jsp:root version="2.0" xmlns:jsp="http://java.sun.com/JSP/Page"> <jsp:output doctype-root-element="colors" doctype-system="colors.dtd" /> <jsp:output omit-xml-declaration="false"/> <![CDATA[<?xml-stylesheet type="text/xsl" href="colors.xsl"?>]]> <colors > <jsp:declaration>static String[] colors = {"red","blue","green"}; </jsp:declaration> <jsp:scriptlet><![CDATA[ for(int i=0; i<3; ++i) { ]]></jsp:scriptlet> <jsp:element name="color"> <jsp:attribute name="id"> <jsp:expression>i</jsp:expression></jsp:attribute> <jsp:expression>colors[i]</jsp:expression> </jsp:element> <jsp:scriptlet>}</jsp:scriptlet> </colors> </jsp:root> Now we can add the XSL We use CDATA because of the <?, ?> etc Still problematic: Which DTD should we use? the DTD should enable every JSP element within every other element… cs236607
Links JSP Tutorial: http://courses.coreservlets.com/Course-Materials/csajsp2.html Advanced Tutorials: http://courses.coreservlets.com/Course-Materials/msajsp.html JSP API: http://tomcat.apache.org/tomcat-5.5-doc/jspapi/ JSP Syntax Reference: http://java.sun.com/products/jsp/syntax/2.0/syntaxref20.html cs236607