Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Java Servlets and JSP: Understanding Session, Context, Init Parameters, and MVC, Study notes of Web Programming and Technologies

An overview of java servlets and jsp (java server pages), focusing on session and context, init parameters, and the mvc (model-view-controller) design pattern. Servlets and jsp are used to create dynamic web content, and this document explains how to use session and context objects to store and retrieve user data, as well as how to configure init parameters and use the mvc design pattern for better application organization.

Typology: Study notes

2012/2013

Uploaded on 01/29/2013

bunkeraditya
bunkeraditya 🇮🇳

4

(2)

8 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
******************** Request and Response ********************
response.setContentType("text/html");
ServletOutputStream out = response.getOutputStream();
out.write();
PrintWriter writer = response.getWriter();
writer.println("______")
String <variable_name> = request.getParameter("name_of_parameter");
String[] <variable_name> = request.getParameterValues("name_of_parameter_with multiple
values present");
request and responce are created per access
******************** SESSION : ********************
Restricted for a particular user or a particular browser
session object can be shared across different servlets
to store user data in server memory we need session object...tomcat gives the session object...
we can use that to save data values at some point during the execution of servlet and retrieve
that data at some other point...
use case - login screens , shopping cart...remembers the data user already sent...
pulls the info frm request and stores it in a session object...
HTTPSession session = request.getSession();
session.setAttribute("__" , __);
.... = (String) session.getAttribute("__"); --this method returns an object so cast it as a
string...
******************** Context : ********************
-across entire application
-shared across both servlets and users
-it's also tomcat implemented...tomcat provide it for us...
suppose i have a dataase application and i do not want to open a database connection for
every access...
i wan't that connection to be opened accross servlets and accross users
use case - initialization code or bulletin board
ServletContext context = request.getServletContext();
pf3
pf4
pf5

Partial preview of the text

Download Java Servlets and JSP: Understanding Session, Context, Init Parameters, and MVC and more Study notes Web Programming and Technologies in PDF only on Docsity!

******************** Request and Response ********************

response.setContentType("text/html");

ServletOutputStream out = response.getOutputStream(); out.write();

PrintWriter writer = response.getWriter(); writer.println("______")

String <variable_name> = request.getParameter("name_of_parameter");

String[] <variable_name> = request.getParameterValues("name_of_parameter_with multiple values present");

request and responce are created per access

******************** SESSION : ********************

Restricted for a particular user or a particular browser session object can be shared across different servlets

to store user data in server memory we need session object...tomcat gives the session object... we can use that to save data values at some point during the execution of servlet and retrieve that data at some other point...

use case - login screens , shopping cart...remembers the data user already sent... pulls the info frm request and stores it in a session object...

HTTPSession session = request.getSession(); session.setAttribute("__" , ); .... = (String) session.getAttribute(""); --this method returns an object so cast it as a string...

******************** Context : ********************

-across entire application -shared across both servlets and users -it's also tomcat implemented...tomcat provide it for us...

suppose i have a dataase application and i do not want to open a database connection for every access... i wan't that connection to be opened accross servlets and accross users

use case - initialization code or bulletin board

ServletContext context = request.getServletContext();

context.setAttribute("__" , ); .... = (String) context.getAttribute("");

******************** Init Parameters ********************

  1. Annotation Type : with other properties in annotation

initParams = {@WebInitParam(name="" , value="")}

getServletConfig().getInitParameter("name_in_the_init_params")

  1. web.xml type

<servlet-name>BeerParamTests</servlet-name> <servlet-class>TestInitParams</servlet-class>

<init-param> <param-name>adminEmail</param-name> <param-value>likewecare@wickedlysmart.com</param-value> </init-param>

note : inside the servlet tag

******************** JSP - JAVA Server Pages ********************

JSP is actually converted to a java class by tomcat...and the java class that gets generated is a servlet... so every jsp is a different way to write a servlet...when u save the jsp and deploy it -- tomcat takes that jsp and converts it into a servlet...every code inside the scriptlet tag gets converted to a code inside doGet or doPost... tomcat generates the servlet and deploys it in a temporary folder different from the folder where our application is deployed rather than putting the code in doGet or doPost , tomcat puts it in method called 'jspService' and jspService in turn gets doGet or doPost every static line e.g HTML code -- goes inside out.write("__")

One Can see the generated java_source_code_file from the jsp in the tomcat folder...after generation of the servlet or java file it get's deployed in a temporary folder called work inside the tomcat folder...

Tomcat --> work --> Catalina --> localhost --> _ --> org --> apache --> jsp the auto-generated java file is in the org+apache+jsp package

In Servlets we initialuized parameters on servlets to servlet basis by using web.xml or annotations how to do it in a jsp file...in order to do that we hav to configure web.xml

<servlet-name>name_u_wanna_give</servlet-name> <jsp-file>path_to_the_jsp_file_itself</jsp-file> -- now here we don't have a servlet cl <init-param> <param-name>____</param-name> <param-value>____</param-value> </init-param>

<servlet-mapping> <servlet-name>name_u_wanna_give</servlet-name> <url-pattern>_____</url-pattern> -- url pattern will be the path of the jsp itself because whenever a jsp is accessed it would wan't this kind of configuration to happen and the url by default is the jsp url itself </servlet-mapping>

what this is telling tomcat is that...this is actually a jsp page and i don't know the servlet name so m just gonna provide a jsp name here and you(tomcat) has to decide that what's the servlet that genrates out of this jsp and then map this servlet name here to the name of the generated servlet...

overriding the init method in JSP...u have to inherit the jspInit() method...how we know that we have to override this method --open the auto-generated java file of the respective servlet and u will know it

A servlet config is something that tomcat passes to us on the creation of the servlet object...what it does is it checks the init parameters in the web.xml and what are the configuration parameters we set there...tomcat passes them into an object called 'servlet-config' and it passes to out init method and it's available for us in the servlet as a member variable called the servlet config...

context object is applicable accross the application...

******************** MVC - Model View Controller ********************

front end design pattern useful for designing web application

Waiter -- Cook -- Presenter analogy...why do we have three different role?

advantage of having three roles separate is there's no mixing of responsibilities or concerns...the waiter doesn't hav to knw how to cook all the waiter does is...take the order and pass it to cook...the cook doesn't worry where's the order coming from... all he does is cook the dish...the presenter doesnn't worry about how to take orders or how to cook... he present's in the proper way.... there can be many presenters or cook...the waiter decides according to the dish ordered [to which cook the dish should be passes and same with the presenter]

Now lets see how it works in a generic scenario...

suppose a user is making a request to a web application or a URL... so the first person who takes this request is the controller...this is the 'C' in the MVC...