



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 5
This page cannot be seen from the preview
Don't miss anything!
******************** 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
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 ********************
initParams = {@WebInitParam(name="" , value="")}
getServletConfig().getInitParameter("name_in_the_init_params")
<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-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...