'What's the difference between including files with JSP include directive, JSP include action and using JSP Tag Files?
It seems that there are two methods for templating with JSP. Including files with one of these statements
<%@ include file="foo.html" %>
<jsp:include page="foo.html" />
or using JSP tag files
// Save this as mytag.tag
<%@ tag description="Description" pageEncoding="UTF-8"%>
<html>
<head>
</head>
<body>
<jsp:doBody/>
</body>
</html>
And in another JSP page call it with
<%@ taglib prefix="t" tagdir="/WEB-INF/tags" %>
<t:mytag>
<h1>Hello World</h1>
</t:mytag>
So which method should I use? Is one now considered deprecated or are they both valid and cover different use cases?
Edit
Isn't using this tag file the same as using an include?
// Save this as product.tag
<%@ tag description="Product templage" pageEncoding="UTF-8"%>
<%@ tag import="com.myapp.Product" %>
<%@ attribute name="product" required="true" type="com.myapp.Product"%>
Product name: ${product.name} <br/>
Quantity: ${product.quantity} <br/>
And call it on another JSP with
<%@ taglib prefix="t" tagdir="/WEB-INF/tags" %>
<t:product>
<c:forEach items="${cart.products}" var="product">
<t:product product="${product}"/>
</c:forEach>
</t:product>
That seems to me to be the very same as using an include and passing parameters to it. So are Tag Files the same as includes?
Solution 1:[1]
<@include> - The directive tag instructs the JSP compiler to merge contents of the included file into the JSP before creating the generated servlet code. It is the equivalent to cutting and pasting the text from your include page right into your JSP.
- Only one servlet is executed at run time.
- Scriptlet variables declared in the parent page can be accessed in the included page (remember, they are the same page).
- The included page does not need to able to be compiled as a standalone JSP. It can be a code fragment or plain text. The included page will never be compiled as a standalone. The included page can also have any extension, though .jspf has become a conventionally used extension.
- One drawback on older containers is that changes to the include pages may not take effect until the parent page is updated. Recent versions of Tomcat will check the include pages for updates and force a recompile of the parent if they're updated.
- A further drawback is that since the code is inlined directly into the service method of the generated servlet, the method can grow very large. If it exceeds 64 KB, your JSP compilation will likely fail.
<jsp:include> - The JSP Action tag on the other hand instructs the container to pause the execution of this page, go run the included page, and merge the output from that page into the output from this page.
- Each included page is executed as a separate servlet at run time.
- Pages can conditionally be included at run time. This is often useful for templating frameworks that build pages out of includes. The parent page can determine which page, if any, to include according to some run-time condition.
- The values of scriptlet variables need to be explicitly passed to the include page.
- The included page must be able to be run on its own.
- You are less likely to run into compilation errors due to the maximum method size being exceeded in the generated servlet class.
Depending on your needs, you may either use
<@include>or<jsp:include>
Solution 2:[2]
Main advantage of <jsp:include /> over <%@ include > is:
<jsp:include /> allows to pass parameters
<jsp:include page="inclusion.jsp">
<jsp:param name="menu" value="objectValue"/>
</jsp:include>
which is not possible in <%@include file="somefile.jsp" %>
Solution 3:[3]
All three template options - <%@include>, <jsp:include> and <%@tag> are valid, and all three cover different use cases.
With <@include>, the JSP parser in-lines the content of the included file into the JSP before compilation (similar to a C #include). You'd use this option with simple, static content: for example, if you wanted to include header, footer, or navigation elements into every page in your web-app. The included content becomes part of the compiled JSP and there's no extra cost at runtime.
<jsp:include> (and JSTL's <c:import>, which is similar and even more powerful) are best suited to dynamic content. Use these when you need to include content from another URL, local or remote; when the resource you're including is itself dynamic; or when the included content uses variables or bean definitions that conflict with the including page. <c:import> also allows you to store the included text in a variable, which you can further manipulate or reuse. Both these incur an additional runtime cost for the dispatch: this is minimal, but you need to be aware that the dynamic include is not "free".
Use tag files when you want to create reusable user interface components. If you have a List of Widgets, say, and you want to iterate over the Widgets and display properties of each (in a table, or in a form), you'd create a tag. Tags can take arguments, using <%@tag attribute> and these arguments can be either mandatory or optional - somewhat like method parameters.
Tag files are a simpler, JSP-based mechanism of writing tag libraries, which (pre JSP 2.0) you had to write using Java code. It's a lot cleaner to write JSP tag files when there's a lot of rendering to do in the tag: you don't need to mix Java and HTML code as you'd have to do if you wrote your tags in Java.
Solution 4:[4]
According to: Java Revisited
Resources included by include directive are loaded during jsp translation time, while resources included by include action are loaded during request time.
Any change on included resources will not be visible in case of include directive until jsp file compiles again. While in case of include action, any change in included resource will be visible in the next request.
Include directive is static import, while include action is dynamic import.
Include directive uses file attribute to specify resources to be included while include action uses page attribute for the same purpose.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Community |
| Solution 2 | Enrique San MartÃn |
| Solution 3 | |
| Solution 4 | Adriano |
