Interface Summary
Interface Summary
The javax.servlet.http package contains a number of classes and interfaces that describe
and define the contracts between a servlet class running under the HTTP protocol and the
runtime environment provided for an instance of such a class by a conforming servlet
container.
Interface Summary
Extends the ServletRequest interface to provide request
HttpServletRequest
information for HTTP servlets.
Extends the ServletResponse interface to provide HTTP-
HttpServletResponse
specific functionality in sending a response.
Provides a way to identify a user across more than one page
HttpSession request or visit to a Web site and to store information about
that user.
Objects that are bound to a session may listen to container
HttpSessionActivationListene
events notifying them that sessions will be passivated and that
r
session will be activated.
Interface for receiving notification events about HttpSession
HttpSessionAttributeListener
attribute changes.
Causes an object to be notified when it is bound to or unbound
HttpSessionBindingListener
from a session.
Deprecated. As of Java(tm) Servlet API 2.1 for security
HttpSessionContext
reasons, with no replacement.
Interface for receiving notification events about HttpSession
HttpSessionListener
lifecycle changes.
This class represents a part or form item that was received
Part
within a multipart/form-data POST request.
METHODS:
These are the parts of a JSP page that are used verbatim in the response.
In simple cases this data will take the form of plain HTML.
This text can be written anywhere in the JSP file. It is copied unchanged, in lexical order,
to the output stream of a response
Model-View-Controller (MVC) is a classic design pattern often used by applications that need
the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean
separation of objects into one of three categories — models for maintaining data, views for
displaying all or a portion of the data, and controllers for handling events that affect the model
or view(s).Because of this separation, multiple views and controllers can interface with the same
model. Even new types of views and controllers that never existed before can interface with a
model without forcing a change in the model design.
Model. The model manages the behavior and data of the application domain,
responds to requests for information about its state (usually from the view), and
responds to instructions to change state (usually from the controller).
Controller. The controller interprets the mouse and keyboard inputs from the user,
informing the model and/or the view to change as appropriate.
It is important to note that both the view and the controller depend on the model. However, the model depends on
neither the view nor the controller. This is one the key benefits of the separation. This separation allows the model to
be built and tested independent of the visual presentation. The separation between view and controller is secondary
in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In
Web applications, on the other hand, the separation between view (the browser) and controller (the server-side
components handling the HTTP request) is very well defined.
Model-View-Controller is a fundamental design pattern for the separation of user interface logic from business logic.
Unfortunately, the popularity of the pattern has resulted in a number of faulty descriptions. In particular, the term
"controller" has been used to mean different things in different contexts. Fortunately, the advent of Web applications
has helped resolve some of the ambiguity because the separation between the view and the controller is so apparent
Custom actions can be used by JSP authors and authoring tools to simplify writing
JSP pages. A custom action can be either an empty or a non-empty action.
An empty tag has no body. There are two equivalent syntaxes, one with separate start
and end tags, and one where the start and end tags are combined. The two following
examples are identical:
<x:foo att="myObject"></foo>
<x:foo att="myObject"/>
A non-empty tag has a start tag, a body, and an end tag. A prototypical example is of
the form:
<x:foo att="myObject" >
BODY
</x:foo/>
The JavaServer Pages(tm) (JSP) specification provides a portable mechanism for the
description of tag libraries.
Description
Interface Summary
The BodyTag interface extends IterationTag by defining additional methods that let
BodyTag
a tag handler manipulate the content of evaluating its body.
For a tag to declare that it accepts dynamic attributes, it must implement this
DynamicAttributes
interface.
The IterationTag interface extends Tag by defining one additional method that
IterationTag
controls the reevaluation of its body.
This interface indicates to the container that a tag handler wishes to be provided
JspIdConsumer
with a compiler generated ID.
Tag The interface of a classic tag handler that does not want to manipulate its body.
The auxiliary interface of a Tag, IterationTag or BodyTag tag handler that wants
TryCatchFinally
additional hooks for managing resources.
3.a. Develop a jsp with a bean in the application scope?
Step4: Create the JSP called BeanCounter.jsp that uses Counter bean and place it in
webapps\myjsp\test folder