CodeGym /Java blog /Tilfældig /Oprettelse af en simpel webapplikation ved hjælp af servl...
John Squirrels
Niveau
San Francisco

Oprettelse af en simpel webapplikation ved hjælp af servlets og JSP'er (del 1)

Udgivet i gruppen
Nødvendig viden for at forstå artiklen: Du har allerede mere eller mindre fundet ud af Java Core og vil gerne se på JavaEE-teknologier og webprogrammering . Det ville give mest mening for dig at studere Java Collections quest , som omhandler emner tæt på artiklen.
Oprettelse af en simpel webapplikation ved hjælp af servlets og JSP'er (del 1) - 1
Dette materiale er den logiske fortsættelse af min artikel At skabe det enkleste webprojekt i IntelliJ Idea Enterprise . I den artikel demonstrerede jeg, hvordan man opretter en fungerende webprojektskabelon. Denne gang vil jeg vise dig, hvordan du opretter en enkel, men fuldstændig attraktiv webapplikation ved hjælp af Java Servlet API og JavaServer Pages API . Vores ansøgning vil have en hjemmeside med to links:
  • et link til en side for tilføjelse af brugere;
  • et link til listen over brugere.
Som før vil jeg bruge IntelliJ Idea Enterprise Edition , Apache Maven (vi forbinder bare nogle afhængigheder) og Apache Tomcat . I sidste ende vil vi "forskønne" vores applikation ved hjælp af W3.CSS -rammen. Vi antager, at du allerede har et tomt projekt, som vi nu vil føje til. Hvis ikke, så kør den første artikel igennem og lav en. Det tager kun et par minutter :)

Lidt om vores fremtidige applikations struktur

Vores hjemmeside (/) vil være en meget almindelig statisk HTML- side med en header og to links/knapper:
  • tilføje en ny bruger (navigerer til / add );
  • se listen over brugere (navigerer til / liste ).
Tomcat vil fange anmodninger om disse adresser og sende dem til en af ​​de to servlets, som vi skal lave (vi angiver tilknytningen i web.xml ). Servlets vil derefter behandle anmodningerne, forberede data (eller gemme data, hvis vi tilføjer en bruger), og overføre kontrol til de relevante JSP-filer , som derefter "renderer" resultatet. Vi gemmer dataene i en almindelig vaniljeliste (Liste).

Opret en statisk startside

Hvis du index.jsp i din webmappe, skal du slette den. Opret i stedet en simpel HTML-fil kaldet index.html i denne mappe:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>My super project!</title>
</head>
<body>
    <!-- header -->
    <div>
        <h1>Super app!<//h1>
    </div>

    <div>       <!-- content -->
        <div>    <!-- button holder -->
            <button onclick="location.href='/list'">List users<//button>
            <button onclick="location.href='/add'">Add user<//button>
        </div>
    </div>
</body>
</html>
Der er ikke noget kompliceret her. I title- tagget angiver vi titlen på vores side. I sideteksten har vi to hoveddivs: header og content . Indholdet div indeholder en holder til vores knapper. Og der har vi to knapper, der fører dig til den tilsvarende adresse med et klik. Du kan køre projektet og se, hvordan det ser ud nu. Hvis du klikker på knapperne, får du 404-fejlsider, fordi vi de tilsvarende sider ikke eksisterer endnu. Men vi kan se, at knapperne virker. Bemærk, at dette ikke er den mest universelle tilgang: Hvis JavaScript er slået fra i browseren, vil disse knapper ikke virke. Men vi antager, at ingen deaktiverer JavaScript. :) Det er klart, du kunne klare dig med simple links, men jeg foretrækker knapper. Du kan gøre det som du foretrækker. Og bekymre dig ikke om det faktum, at mine eksempler vil have mange divs . Vi fylder dem med styles senere, og alt vil se smukkere ud. :)

Opret JSP-filer for at gengive resultatet

I samme webmappe skal du oprette en mappe, hvor vi tilføjer vores JSP-filer . Jeg kaldte det ' visninger ', men endnu en gang kan du improvisere. I denne mappe opretter vi to JSP-filer:
  • add.jsp — en side til tilføjelse af brugere;
  • list.jsp — side for at vise listen over brugere.
Tildel passende sideoverskrifter til dem. Noget som " Tilføj ny bruger " og " Brugerliste ", så lader vi det være sådan.

Opret to servlets

Servlets vil modtage og behandle de anmodninger, som Tomcat sender dem. I mappen src/main/java skal du oprette app- pakken, hvor vi lægger vores kildekode. Andre pakker vil også gå dertil. Så for at forhindre, at disse pakker oprettes inde i hinanden, opretter vi en klasse i apppakken (vi sletter den senere). Opret nu tre forskellige pakker i app- pakken:
  • entities — vores entiteter (klassen, der beskriver brugerobjekter) går her;
  • model — det er her vores model går (vi taler om dette lidt senere);
  • servlets - og det er her, vores servlets går.
Når du har gjort dette, kan du roligt slette den klasse fra app- pakken (hvis du selvfølgelig har oprettet den). Opret to klasser i servlets- pakken:
  • AddServlet — behandler anmodninger sendt til / add ;
  • ListServlet — behandler anmodninger sendt til / liste .

Forbindelse af afhængigheder i Maven

Tomcat 9. * implementerer specifikationerne for Servlet 4.0 og JavaServer Pages 2.3 . Det er, hvad der står i anden linje i det første afsnit af Tomcat 9's officielle dokumentation. Det betyder, at hvis du, ligesom jeg, bruger denne version af Tomcat , så vil den kode, du vil skrive og køre, bruge disse versioner. Men vi vil gerne have disse specifikationer i vores projekt, så vores kode, som bruger dem, i det mindste kompileres med succes. Og for at gøre dette skal vi indlæse dem i vores projekt. Det er her Maven kommer til undsætning.

Den generelle regel er denne: hvis du skal forbinde noget til dit projekt ved hjælp af Maven:

  • gå til repository-webstedet fra Maven;
  • find den nødvendige version af det nødvendige bibliotek;
  • få den afhængighedskode, der skal indsættes i din pom.xml;
  • sæt ind! :)
Lad os begynde. Forbered først POM-filen . Et sted efter /version- indgangen, men før /project , indsæt følgende:

<dependencies>

</dependencies>
Vi gør dette for at indikere, at vi vil angive de nødvendige afhængigheder inden for disse tags. Gå nu til mvnrepository.com . Der er et søgefelt øverst. For at starte, søg efter ' servlet '. Det første resultat, som er blevet brugt mere end syv tusinde gange, passer os. Husk, vi har brug for version 4.0 (til Tomcat 9). Andre versioner kan være passende til ældre implementeringer. Dette er en ret nyere version, så der er ikke så mange anvendelsesmuligheder. Men vi har brug for det. En side åbnes, hvor du kan få koden til denne afhængighed for en række forskellige pakkeadministratorer, eller du kan blot downloade den. Men da vi vil forbinde det ved hjælp af Maven, vælger vi koden på Maven-fanen. Vi kopierer og indsætter i afhængighedsafsnittet i vores POM-fil. Hvis du får en meddelelse, der spørger, om du vil aktivere automatisk import i nederste højre hjørne af IDEA , skal du gå videre og acceptere det. Hvis du ved et uheld nægtede, skal du gå til " Indstillinger " og aktivere automatisk import manuelt: Indstillinger (Ctrl + Alt + S) -> Build, Execution, Deployment -> Maven -> Importer .og IDEA-konfigurationsfilerne for dette projekt synkroniseret. Efter samme princip finder og forbinder vi JavaServer Pages 2.3 (søg efter "JSP"). Og da vi allerede har startet Maven, lad os bare fortælle det, at vores kildefiler følger Java 8-syntaks, og at vi skal kompilere dem til bytekode for den version. Efter alle disse trin vil vores pom.xml se sådan ud:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>cc.codegym.info.fatfaggy</groupId>
    <artifactId>my-super-project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compile.source>1.8</maven.compile.source>
        <maven.compile.target>1.8</maven.compile.target>
    </properties>

    <dependencies>
        <!-- Servlet API 4.0 for tomcat 9 -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>4.0.0</version>
            <scope>provided</scope>
        </dependency>

        <!-- JavaServer Pages API 2.3 for tomcat 9 -->
        <dependency>
            <groupId>javax.servlet.jsp</groupId>
            <artifactId>javax.servlet.jsp-api</artifactId>
            <version>2.3.1</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

</project>

Gør vores servlets til rigtige servlets

I øjeblikket er det par servlets, vi oprettede, faktisk almindelige klasser. De har ingen funktionalitet. Men nu har vi forbundet Servlet API til vores projekt, og derfor kan vi bruge dets klasser. For at gøre vores servlets "rigtige", er alt, hvad vi skal gøre, at få dem til at arve HttpServlet -klassen.

Kortlægning eller opmærkning

Nu ville det være rart at fortælle Tomcat på en eller anden måde , at anmodninger om / add- adressen behandles af vores AddServlet , og anmodninger om / list- adressen håndteres af ListServlet . Denne proces kaldes mapping (markup). Dette gøres i web.xml efter samme princip:
  • for at starte, beskriv servlet'en (giv et navn og angiv stien til selve klassen);
  • bind derefter denne servlet til en specifik adresse (angiv servletens navn, som vi lige har givet den, og angiv den adresse, hvis anmodninger skal sendes til denne servlet).
Beskriv servletten:

<servlet>
    <servlet-name>add</servlet-name>
    <servlet-class>app.servlets.AddServlet</servlet-class>
</servlet>
Bind det nu til adressen:

<servlet-mapping>
    <servlet-name>add</servlet-name>
    <url-pattern>/add</url-pattern>
</servlet-mapping>
Som du kan se, er servlet-navn det samme i begge tilfælde. Som et resultat ved Tomcat , at hvis en anmodning om /add modtages, skal den sendes til app.servlets.AddServlet. Vi gør det samme med den anden servlet. I sidste ende har vores web.xml omtrent følgende indhold:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <!-- add servlet -->
    <servlet>
        <servlet-name>add</servlet-name>
        <servlet-class>app.servlets.AddServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>add</servlet-name>
        <url-pattern>/add</url-pattern>
    </servlet-mapping>

    <!-- list servlet -->
    <servlet>
        <servlet-name>list</servlet-name>
        <servlet-class>app.servlets.ListServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>list</servlet-name>
        <url-pattern>/list</url-pattern>
    </servlet-mapping>
</web-app>
I øvrigt lavede vi ikke opmærkning til startsiden (/). Faktum er, at vi ikke har brug for det i dette tilfælde. Vores hjemmeside er en simpel HTML-fil, der kun viser to knapper. Det har ikke noget dynamisk indhold, så vi behøver ikke at oprette en separat servlet for anmodninger fra / , der ikke gør andet end at videresende eksekvering til en eller anden JSP (som også skulle oprettes) for at tegne to knapper til os. Vi har ikke brug for dette. En statisk side passer os. Når Tomcat modtager en anmodning, vil den kontrollere, om der er en enkelt servlet, der kan behandle anmodningen om den pågældende adresse, og så vil den se, at denne adresse faktisk allerede indeholder den klar HTML- fil, som den vil servere. Vi kan køre vores applikation igen (genstarte serveren eller geninstallere den igen - hvad end du foretrækker) og sikre, at hjemmesiden er gengivet, intet er gået i stykker, og overgangene sker, når vi klikker på knapperne (selvom vi igen får en fejl). Forresten, hvor vi før fik en 404-fejl, får vi nu en 405. Det betyder, at mappingen virkede og servlets blev fundet, men de havde ingen passende metode til at håndtere anmodningen.

Kort digression: hvad sker der "under motorhjelmen"?

Du har sikkert allerede tænkt over, hvordan vores applikation fungerer i Tomcat. Hvad sker der derinde? Og hvor er main() metoden? Så snart du går til localhost:8080 i din browser, sender browseren en anmodning til denne adresse ved hjælp af HTTP-protokollen. Jeg håber, du allerede er klar over, at der er mange forskellige typer anmodninger, og de mest populære er GET og POST. Hver anmodning skal besvares. En GET-anmodning forventes at modtage et svar med klar-til-brug HTML-kode, returneret til browseren. Browseren erstatter derefter koden vil alle de smukke bogstaver, knapper og formularer. En POST-anmodning er lidt mere interessant, da den også indeholder nogle oplysninger. Antag for eksempel, at du indtaster legitimationsoplysninger i en registrerings- eller loginformular på et websted og klikker på "Send". Dette medfører, at en POST-anmodning med dine personlige oplysninger sendes til serveren. Serveren modtager disse oplysninger, behandler dem og returnerer nogle svar (for eksempel en HTML-side med din profil). Den væsentligste forskel mellem dem er, at GET-anmodninger kun bruges til at hente data fra serveren, mens POST-anmodninger indeholder nogle oplysninger (og dataene på serveren kan ændre sig). Når du f.eks. uploader dit billede til serveren, føres det dertil i en POST-anmodning, og serveren tilføjer det til databasen, dvs. der sker en ændring. Nu tilbage til Tomcat. Når den modtager en anmodning fra en klient, ser den på adressen. Den kontrollerer, om der er en passende servlet til at behandle anmodninger om den pågældende adresse (eller en tilgængelig ressource, der kan returneres med det samme). Hvis den ikke finder noget at returnere, så svarer den med en 404-fejl i stedet for en HTML-side. Men hvis den finder en passende servlet "sidder" på den adresse, så ser den på anmodningstypen (GET, POST eller noget andet) og spørger servlet'en, om den har en metode, der kan håndtere denne type forespørgsler. Hvis servlet siger, at den ikke ved, hvordan den skal håndtere denne type, såTomcat returnerer en 405-kode. Og det er bare, hvad der skete i vores projekt. Men hvis der findes en passende servlet, og den har en passende metode, så opretter Tomcat et servlet-objekt, starter det på en ny tråd(hvilket lader det køre på egen hånd), og Tomcat fortsætter sit eget arbejde, accepterer og sender anmodninger. Derudover opretter Tomcat yderligere to objekter: en HttpServletRequest (som jeg vil kalde "anmodningen" for kort), og en HttpServletResponse (som jeg vil kalde "svaret"). Det sætter alle data modtaget fra klientens anmodning i det første objekt, så alle disse data kan udtrækkes fra det. Og så efter alt dette, sender den disse to disse objekter til den passende metode for den servlet, der blev startet på en separat tråd. Så snart servletten er færdig med sit arbejde og har et svar klar til at blive sendt til klienten, vifter den med et flag mod Tomcat og siger "Jeg er færdig. Alt er klar". Tomcat modtager svaret og sender det til klienten. Dette gør det muligt for Tomcat at modtage anmodninger og sende svar, uden at blive distraheret, og alt arbejdet udføres af servlets, der kører på separate tråde. Det betyder, at når vi skriver servlet-koden, bestemmer vi, hvilket arbejde der skal udføres. Og du kan tænke på, at main()-metoden er placeret inde i selve Tomcat (jep, den er skrevet i Java), og når vi "starter" Tomcat, startes main()-metoden. Oprettelse af en simpel webapplikation ved hjælp af servlets og JSP'er (del 1) - 2

Brug servlets til at fange GET-metoder og sende superenkle svar

I øjeblikket har vores servlets ingen egnede metoder (GET), så Tomcat returnerer en 405-fejl. Lad os skabe dem! HttpServlet-klassen, vi vores servlets arver, erklærer forskellige metoder. For at tildele specifik kode til metoderne tilsidesætter vi dem simpelthen. I dette tilfælde skal vi tilsidesætte doGet()metoden i begge servlets.

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

}
Som du kan se, tager denne metode to argumenter: req (request) og resp (respons). Det er netop de objekter, som Tomcat opretter og udfylder for os, når den kalder den passende metode i servlet'en. Til at begynde med laver vi de enkleste svar. For at gøre dette tager vi resp-objektet og henter et PrintWriter-objekt fra det. Denne type objekt bruges til at komponere et svar. Vi bruger den til at udskrive en simpel streng.

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    PrintWriter writer = resp.getWriter();
    writer.println("GET method from AddServlet");
}
Vi vil gøre noget lignende i ListServlet, og så genstarter vi vores server. Som du kan se, virker alt! Når du klikker på knapperne, får du sider med den tekst, som vi "skrev" med PrintWriteren. Men de JSP-filer, som vi forberedte til at generere sider med svar, bliver ikke brugt. Det er simpelthen fordi de aldrig bliver henrettet. Vores servlet opretter selv svaret og kører færdigt og signalerer til Tomcat, at den er klar til at svare klienten. Tomcat tager bare svaret og sender det tilbage til klienten. Lad os overføre kontrol fra servlets til JSP-filerne. Vi ændrer koden for vores metoder som følger:
  • vi henter et request dispatcher-objekt fra request-objektet og giver det adressen på den JSP-side, som vi ønsker at overføre kontrol til;
  • vi bruger dette objekt til at overføre kontrol til den angivne JSP-side, og vi glemmer ikke at videregive de anmodnings- og svarobjekter, vi modtog fra Tomcat.

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    RequestDispatcher requestDispatcher = req.getRequestDispatcher("views/add.jsp");
    requestDispatcher.forward(req, resp);
}
I body-tagget på JSP-siderne kan du tilføje noget, så vi tydeligt kan se, hvilken side der bliver vist. Når du har gjort det, genstart serveren og kontroller. Vi klikker på knapperne på hovedsiden og siderne åbner, hvilket betyder at anmodningerne sendes til servlets. Derefter overføres kontrollen til JSP-siderne, som nu bliver gengivet. Det er alt for nu. I den næste del af denne artikel vil vi arbejde på funktionaliteten af ​​vores applikation.
Kommentarer
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION