I understand that to use jstl on JSP, one need to include this taglib in the jsp:
<%#taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
However, I was wondering if there is a way to refer this item via localhost.
====
For example, I can use this jquery which I downloaded and placed in my resource folder
<script type="text/javascript"
src="${pageContext.request.contextPath}/js/lib/jquery.min.js"></script>
instead of referring jquery from http://ajax.googleapis.com
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
====
Question: is there a way to refer jstl from local folder, instead of look up at http://java.sun.com?
Asking this question is because my client wanted a web app hosted on local network and have no internet access. so, no external referencing.
p/s: please no chit-chat, just written solution.
p/s/s: please don't advise me to change my programming language, framework or upgrade my java version. It is a restriction for my work.
The URI is a Universal Resource Identifier, it is NOT a locator (URL) or src of file.
This means that the URI is used to uniquely identify each taglib in an internal registry of taglibs.
This URI is specified in *.tld files in jstl jar. You can check it extracting jar and goto jstl-1.2\META-INF
So you cannot change this URI. It is accessible even without internet.
Related
I am having problems displaying an image in my .jsp file.
The image no_image.jpg is located inside the following directory of my Spring MVC application:
SpringProject\src\main\webapp\assets\images\no_image.jpg
I am trying to access it through my .jsp file like this:
<img src="${pageContext.request.contextPath}/assets/images/no_image.jpg"></a>
Project structure (using apache Netbeans IDE 11):
However this does not seem to display the image, does anyone have any ideas why?
Probably the Expression Language is treated as plain text. To tell the JSP engine to process such expressions, add <%# page isELIgnored="false"%> before the <html> tag in your JSP page (at the top, where you have other "%#"-like directives or JSTL imports). Unfortunately, this parameter's value defaults to true.
I have found the solution. For anyone else experiencing this issue, a possible solution is to put the following into your spring configuration .xml file: (Where you define your base package for the project, my one is named spring-config.xml)
<mvc:resources mapping="/assets/**" location="/assets/"/>
So there seems to be a few ways to include jsp files in jsp files, being:
<%# include file="header.jsp" %>
<jsp:include page="header.jsp" />
<c:import url="header.jsp" />
<tagfiles:tagfile />
So which one should I use and why? What advantages / disadvantages do they come with?
The include directive, makes a copy of the included page and copies it into a JSP page (the "including page") during translation. This is known as a static include (or translate-time include) and uses the following syntax:
<%# include file="/jsp/userinfopage.jsp" %>
Two alternatives exist for the dynamic include
The jsp:include tag, described in "Standard Actions: JSP Tags", dynamically includes output from the included page within the output of the including page during execution. This is known as a dynamic include (or runtime include) and uses the following syntax:
<jsp:include page="/jsp/userinfopage.jsp" flush="true" />
<c:import url="header.jsp" />
Unlike jsp:include, the c:import action provides a mechanism to access resources that can be specified through a URL, thus allowing page authors to get access to resources that reside outside the Web application. On the other hand, it lacks the ability to flush the response. Finally, c:import is comparatively more heavyweight and is therefore not appropriate when a lightweight solution is sought.
tagfiles are basically templates, which are like generic and can render some common views, but internally they will themselves use html tags itself.but not much of use while including jsp pages.
In my Project, I have used following approach
<jsp:include page="header.jsp" />
I have used this for loading specific div element instead of refreshing whole page.
This can be done by using JQuery's load method.
Including JSP file allows us to reuse the template in many places. Just write template code in JSP file and use it wherever required.
JSP page directives works at translation time while standerd actions works at run time.
You can tagfiles for calling functions on server side. You can also use tagfiles for creation of templates.
I'm building a taglib with a few custom tags. Some of these require a bit of JavaScript to work properly. What would be the best way to add the JavaScript so that it's included in the taglib jar?
The most obvious approach to me would be to put it into the custom tags' doStartTag() method like this pageContext.getOut().print("<script>my js</script>");, which I don't like for 2 reasons: It looks absolutely horrible and it gets added every time the tag gets used on a page.
I'm looking for a solution that lets me keep the JavaScript in a separate .js file that rests somewhere in the taglib jar and gets included only once per page whenever a custom tag is used.
Is there any extended JSP taglib available? Basically, because of project constraints, we're using a home-grown framework and working with JSPs. We want a taglib that will help us work easily with html forms and form elements and provide some sort of binding. Something like struts html tablib. I'm not sure if we can use the struts taglib standalone?
The best solution I can provide for you is to use a retired tag library from jakarta.
It still works but it is no longer supported or maintained by them.
The link can be found here
The one you will be interested in is the "input" tag library which has tags for the following fields:
form
text
password
textarea
hidden
select
option
radio
checkbox
There should be no problem using Struts with appropriate JAR files in Web App lib folders (put all the Struts JARs in there)
Is there somehow that I can invoke Java running on a server from a web browser? I would like:
User navigates to URL in a browser
User fills in input boxes (text)
User presses submit button
Input fields are sent as parameters to java that is executing on the server
A new html page is displayed that was generated by the java running on the server.
What is the standard way to do this, or something similar to this.
I think with PHP this would be relatively simple. I think that you would just pass arguments after the URL like this: www.mysite.com/folder?arguments.
Yes, this is possible (and is extremely common). Two of the most common ways are Java Servlets (where responses are generated purely via Java code) and Java Server Pages (where server logic is intermingled within HTML, similar to ASP or PHP).
There are countless ways to serve HTML from Java but virtually all of them rely on java servlets and java server pages (JSPs) which are Java's specification for handling web requests.
The absolute bare minimum to get going:
Install Java EE SDK ensuring to also install Netbeans and Glassfish.
Launch Netbeans and create a "Java Web" / "Web Application" project
Enter a project name, e.g. MyWebApp
In the Server and Settings screen, you need to Add... your server so do so. Point to the file location of your Glassfish server and enter the admin name and password
Ignore the framework stuff and Finish
NetBeans will generate a sample app and you can click straightaway on Run Main Project. It will deploy your app to Glassfish and load http://localhost:8080/MyWebApp/ from your default browser
Important things to note:
A file called web.xml tells the host server some basics about your web app. This file can contain a lot of other stuff but the default is some boiler plate. The most interesting part says <welcome-file>index.jsp</welcome-file> which means when you load http://localhost:8080/MyWebApp/ it will default to load index.jsp.
The index.jsp is what gets loaded if you don't specify a page to the server. If you look at index.jsp it's just HTML with some JSP markup.
<%#page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<h1>Hello World!</h1>
</body>
</html>
Creating new JSPs is as simple as writing HTML. Netbeans has a wizard to create a simple JSP.
You can embed chunks of Java into a .jsp easily and step in and out of Java / HTML with the <% %> notation such as
<%
for (int i = 0; i < 10; i++) {
%>
Hello <%=i%>
<% } %>
Glassfish is just one possible app server. As long as you write compliant code it should functional with only minimal or zero modifications on any other implementation of Java Servlet / JSP spec. e.g. Jetty, Tomcat, oc4j, JBoss, WebSphere etc.
This is just the tip of the iceberg. You can make things as simple or complex as you like.
Once you know the basics then it's up to you how deep you go. More advanced topics would be:
Taglibraries - these can remove a lot of java clutter and are considered more correct
Expressions - using expressions inside JSP pages to reduce the need for messy <%= notation
Custom servlets let you move model / business stuff into a Java class and leave the .jsp to just presentational
MVC web frameworks like Struts, Spring etc.
Security & filtering
It's a massive subject but it's fairly easy to do something quick and dirty.
As a followup to Mark Peters answer, you need a java web server like Tomcat or GlassFish in order to use servlets or jsps. There are a lot of great frameworks for Java that help you abstract away from the original servlet classes, but I'll let you look those up and decided if you even need them for something this simple.
If you want to pass arguments in a URL, then easier approach is Axis
You can display result with javascript on your page.
If you want to pass arguments in a URL, then easier approach is Axis
My school has an apache server that we are required to use. I was not allowed to install tomcat. I ended up invoking my server side Java using PHP. Not the most beautiful solution but it works.