1 00:00:03,710 --> 00:00:07,605 Nun, da wir über Mongoose Population gelernt haben, 2 00:00:07,605 --> 00:00:14,040 und wie es uns ermöglicht, ein Dokument mit Informationen aus einem anderen Dokument zu füllen. 3 00:00:14,040 --> 00:00:20,605 In dieser Übung werden wir den Express-Server ändern, an dem wir bisher gearbeitet haben. 4 00:00:20,605 --> 00:00:25,580 In dem Schüsselschema, das wir früher definiert haben, hatten wir Kommentare. 5 00:00:25,580 --> 00:00:28,365 Für die Kommentare hatten wir das Autorenfeld 6 00:00:28,365 --> 00:00:31,490 , das wir verwenden, um die Details über den Autor zu speichern. 7 00:00:31,490 --> 00:00:40,815 In dieser Übung verwandeln wir das Autorenfeld in einen Verweis auf ein Benutzerdokument, 8 00:00:40,815 --> 00:00:46,265 und wir werden Mongoose Population verwenden, um die Informationen in 9 00:00:46,265 --> 00:00:50,330 das Geschirr Dokument zu füllen, wie und wenn erforderlich, 10 00:00:50,330 --> 00:00:54,440 um die Informationen an den Kunden zu liefern. 11 00:00:54,440 --> 00:00:59,960 Jetzt sollte die Verwendung von bevölkerten und Mungo Bevölkerung 12 00:00:59,960 --> 00:01:05,550 vernünftig durchgeführt werden, um nicht zu viel Overhead auf der Serverseite verursachen. 13 00:01:05,550 --> 00:01:06,890 Jetzt in dieser Übung 14 00:01:06,890 --> 00:01:09,395 werden wir es einfach verwenden, um die Informationen 15 00:01:09,395 --> 00:01:13,280 in das Autorenfeld unserer Kommentare zu füllen. 16 00:01:13,280 --> 00:01:18,660 Also, lassen Sie uns mit der Übung fortfahren, um zu lernen, wie wir Mongoose Bevölkerung verwenden. 17 00:01:18,660 --> 00:01:21,455 Um mit dieser Übung zu beginnen, 18 00:01:21,455 --> 00:01:25,315 wechseln Sie zum Projekt und öffnen Sie die Datei user.js. 19 00:01:25,315 --> 00:01:27,730 Also, in der Datei user.js 20 00:01:27,730 --> 00:01:29,600 speichern wir das Benutzerschema. 21 00:01:29,600 --> 00:01:35,515 Ich werde das Benutzerschema ändern, indem ich ein paar weitere Felder darin hinzufüge. 22 00:01:35,515 --> 00:01:38,220 Einer ist der Vorname, 23 00:01:38,220 --> 00:01:40,070 der 24 00:01:40,070 --> 00:01:48,115 vom Typ string sein wird und 25 00:01:48,115 --> 00:01:52,025 der Standardwert wäre eine leere Zeichenfolge. 26 00:01:52,025 --> 00:01:56,555 Also, der Vorname, wie der Name schon sagt, 27 00:01:56,555 --> 00:02:03,630 speichert den Vornamen für den Benutzer und dann haben wir ein anderes Feld namens Nachname, 28 00:02:03,630 --> 00:02:06,540 das auch von der gleichen Art ist. 29 00:02:06,540 --> 00:02:13,540 Also, ich werde nur diese zwei Stücke von Informationen kopieren und dann kopieren Sie es 30 00:02:13,540 --> 00:02:20,735 hier und so jetzt unser Benutzerdokument enthält, 31 00:02:20,735 --> 00:02:22,840 zusätzlich zu dem Benutzernamen und Passwort, 32 00:02:22,840 --> 00:02:26,760 Benutzernamen und Still und Salz, die wir zuvor gesehen haben, 33 00:02:26,760 --> 00:02:34,450 Das wird automatisch durch den Pass lokalen Mongoose Modul hinzugefügt . 34 00:02:34,450 --> 00:02:39,840 Wir haben auch den Vor- und Nachnamen für den Benutzer, der hier definiert wird. 35 00:02:39,840 --> 00:02:43,505 Später werden wir sehen, wie wir 36 00:02:43,505 --> 00:02:50,765 diese Werte initialisieren würden, indem wir den Registrierungsprozess des Benutzers ändern. 37 00:02:50,765 --> 00:02:52,950 Jetzt, sobald wir dies abgeschlossen haben, 38 00:02:52,950 --> 00:02:56,599 so dass auf diese Weise die Informationen des Benutzers 39 00:02:56,599 --> 00:03:00,880 einfach abgerufen werden können, indem Sie das Benutzerdokument hier nachschlagen. 40 00:03:00,880 --> 00:03:05,200 Also, jetzt, da wir die Informationen über den Benutzer im Benutzerdokument haben, 41 00:03:05,200 --> 00:03:08,560 gehen in das Dish-Schema, 42 00:03:08,560 --> 00:03:11,015 also gehen Sie in dishes.js Datei. 43 00:03:11,015 --> 00:03:13,260 Im Dish-Schema früher 44 00:03:13,260 --> 00:03:18,465 haben wir den Autor des Dokuments in Form einer Zeichenfolge hier gespeichert. 45 00:03:18,465 --> 00:03:22,700 Jetzt werden wir die Tatsache nutzen, dass wir die 46 00:03:22,700 --> 00:03:27,425 Unterstützung der Mungo Bevölkerung haben. 47 00:03:27,425 --> 00:03:33,740 Also werde ich das Kommentarfeld von einer Zeichenfolge in 48 00:03:33,740 --> 00:03:41,975 Mungo Schema-Typen Objekt-ID umwandeln. 49 00:03:41,975 --> 00:03:49,120 Also, auf diese Weise, tut mir leid, falsches Feld. 50 00:03:49,120 --> 00:03:53,135 Ich wollte das Autorenfeld in 51 00:03:53,135 --> 00:04:02,295 Mungo Schema-Typen Objekt-ID umwandeln. 52 00:04:02,295 --> 00:04:05,390 Also, das Autorenfeld jetzt anstatt eine Zeichenfolge zu speichern, 53 00:04:05,390 --> 00:04:10,835 wird einen Verweis auf das Benutzerdokument haben. 54 00:04:10,835 --> 00:04:14,105 Wenn ich also das Autorenfeld in diesen Typ umwandle, 55 00:04:14,105 --> 00:04:20,180 wird die zweite Eigenschaft, die ich hier definiert habe, eine Referenz 56 00:04:20,180 --> 00:04:25,229 sein, die ein Verweis auf das Benutzermodell wäre. 57 00:04:25,229 --> 00:04:27,980 Auf diese Weise 58 00:04:27,980 --> 00:04:31,370 verbinden wir nun dieses Autorenfeld und dieses Autorenfeld 59 00:04:31,370 --> 00:04:37,585 speichert einfach einen Verweis auf die ID des Benutzerdokuments, 60 00:04:37,585 --> 00:04:43,790 anstatt die Details über den Autor in Form eines Namens zu speichern. 61 00:04:43,790 --> 00:04:45,100 Nun, wenn wir das tun, 62 00:04:45,100 --> 00:04:48,350 können wir Mungo Populate verwenden, um 63 00:04:48,350 --> 00:04:53,115 diese Informationen in unser Geschirr Dokument zu füllen, wann immer es erforderlich ist. 64 00:04:53,115 --> 00:04:58,595 Also, mit dieser Änderung des Schemas Gerichte, in der Datei dishes.js, 65 00:04:58,595 --> 00:05:05,910 werden wir jetzt den Geschirrrouter aktualisieren, um die Mungo Population zu verwenden. 66 00:05:05,910 --> 00:05:09,030 Also, gehen Sie zu dishRouter.js. 67 00:05:09,030 --> 00:05:16,120 In Gericht Router, daran erinnern, dass, wenn wir ein Gericht hier bekommen, 68 00:05:16,120 --> 00:05:19,470 jetzt, wenn Sie das Gericht hier bekommen, 69 00:05:19,470 --> 00:05:23,820 sagen wir Gerichte dann finden. 70 00:05:23,820 --> 00:05:26,610 Also, genau an diesem Punkt, 71 00:05:26,610 --> 00:05:36,005 werden wir sagen, Gerichte finden und wir werden danach sagen, bevölkern. 72 00:05:36,005 --> 00:05:41,924 Also, wir verwenden die Bevölkerung Unterstützung in Mungo 73 00:05:41,924 --> 00:05:48,165 und wir werden sagen, füllen Kommentare Autor. 74 00:05:48,165 --> 00:05:49,740 Also, indem wir dies angeben, 75 00:05:49,740 --> 00:05:51,060 sagen wir, wenn 76 00:05:51,060 --> 00:05:58,750 das Geschirr Dokument konstruiert wurde, um die Antwort an den Benutzer zurückzusenden, 77 00:05:58,750 --> 00:06:05,810 wir werden das Autorenfeld dort aus dem Benutzerdokument dort füllen. 78 00:06:05,810 --> 00:06:09,095 Dieser Aufruf an das Populate stellt also sicher, dass 79 00:06:09,095 --> 00:06:14,665 das andere Feld mit den Informationen nach Bedarf gefüllt wird. 80 00:06:14,665 --> 00:06:18,565 In ähnlicher Weise gehen Sie zum Gericht ID hier, 81 00:06:18,565 --> 00:06:21,660 auch in der Schale ID, das gleiche. 82 00:06:21,660 --> 00:06:31,680 Wir werden sagen, füllen und Kommentare Autor hinzugefügt 83 00:06:31,680 --> 00:06:37,320 in die Gerichte finden durch ID 84 00:06:37,320 --> 00:06:43,395 im get der /dish ID Endpunkt. 85 00:06:43,395 --> 00:06:54,350 In ähnlicher Weise, in den Kommentaren auch, wenn wir das Gericht abrufen, 86 00:06:54,520 --> 00:07:02,370 werden wir sagen, füllen Sie Kommentare Autor hier und die 87 00:07:02,370 --> 00:07:09,900 gleiche Sache auch in der Schale Router, 88 00:07:09,900 --> 00:07:13,695 Gericht ID Kommentare, Kommentar ID auch. 89 00:07:13,695 --> 00:07:16,530 Je größer diese Informationen dort bevölkert werden. 90 00:07:16,530 --> 00:07:22,620 Das bedeutet natürlich, dass Sie, wenn Sie das Gericht veröffentlichen, 91 00:07:22,620 --> 00:07:30,090 früher die Autoreninformationen in den Nachrichtentext aufnehmen. 92 00:07:30,090 --> 00:07:35,120 Also, jetzt hier, wenn wir versuchen, den Kommentar in das zu schieben, 93 00:07:35,120 --> 00:07:41,370 so dass dieser Beitrag entspricht dem Gericht ID Kommentarfeld. 94 00:07:41,370 --> 00:07:46,280 So haben wir einen Kommentar zu einem bestimmten Gericht gepostet. 95 00:07:46,280 --> 00:07:48,570 Also, jetzt in diesem Beitrag, 96 00:07:48,570 --> 00:07:53,890 da wir die Informationen über den Autor nicht mehr speichern, 97 00:07:53,890 --> 00:08:02,400 also was wir tun müssen, ist, wenn wir den Artikel in das Autorenfeld dort schieben. 98 00:08:02,400 --> 00:08:06,720 Also, hier, wenn Sie die Informationen in das Gericht füllen, 99 00:08:06,720 --> 00:08:10,680 müssen wir ersten- 100 00:08:12,010 --> 00:08:16,430 Daran erinnern, dass der Körper den Kommentar bereits enthält, 101 00:08:16,430 --> 00:08:21,505 aber die Eigenschaft des Autors wird nicht in den Körper der Nachricht im Buch, 102 00:08:21,505 --> 00:08:26,020 aber je nachdem, welcher Benutzer diese Informationen veröffentlicht, 103 00:08:26,020 --> 00:08:29,250 können wir füllen Sie sofort das Autorenfeld aus. 104 00:08:29,250 --> 00:08:32,535 Woher wissen wir nun, welcher Benutzer diese Informationen veröffentlicht? 105 00:08:32,535 --> 00:08:38,165 Die Tatsache, dass wir den Verifizierungsbenutzer hier für den Beitrag gemacht haben, 106 00:08:38,165 --> 00:08:42,115 bedeutet, dass ein bestimmter Benutzer diese Informationen veröffentlicht, 107 00:08:42,115 --> 00:08:44,250 und indem wir den Benutzer verifizieren, 108 00:08:44,250 --> 00:08:50,415 hätten wir bereits den req.user in das Anforderungsobjekt geladen. 109 00:08:50,415 --> 00:08:51,925 Im Anforderungsobjekt 110 00:08:51,925 --> 00:08:55,565 können wir in gehen und sagen Wrack Benutzer, 111 00:08:55,565 --> 00:08:59,010 und dann Unterstrich ID hier. 112 00:08:59,010 --> 00:09:01,910 Also, lassen Sie mich noch einmal diesen Punkt wiederholen, 113 00:09:01,910 --> 00:09:05,760 wie erhalten wir hier die Informationen des Autors? Denken Sie 114 00:09:05,760 --> 00:09:10,470 nun daran, dass wir das Schemas Gerichte aktualisiert haben, 115 00:09:10,470 --> 00:09:13,875 so dass das Autorenfeld im Kommentar einfach 116 00:09:13,875 --> 00:09:20,915 die Objekt-ID speichert, die sich auf den Benutzer bezieht, der diesen Kommentar veröffentlicht. 117 00:09:20,915 --> 00:09:24,450 Woher wissen wir nun, welcher Benutzer diesen Kommentar veröffentlicht? 118 00:09:24,450 --> 00:09:27,085 Nun noch einmal, um diesen Punkt zu wiederholen, 119 00:09:27,085 --> 00:09:31,825 erinnern Sie sich, dass, wenn wir den Benutzer hier durch Aufruf von authentifizieren verifizieren Benutzer überprüft, 120 00:09:31,825 --> 00:09:37,590 der Pass autorisierte JWT würde 121 00:09:37,590 --> 00:09:45,120 die Benutzerinformationen in den Anforderungstext in Form von req.user geladen haben. 122 00:09:45,120 --> 00:09:48,470 Dieser Benutzer enthält also die ID 123 00:09:48,470 --> 00:09:52,520 des bestimmten Benutzers, der diesen Kommentar tatsächlich veröffentlicht. 124 00:09:52,520 --> 00:09:55,730 Also, wir haben bereits die Authentizität des Benutzers überprüft, 125 00:09:55,730 --> 00:10:01,400 und so kann die Benutzer-ID einfach erhalten werden, indem Sie req.user sagen. 126 00:10:01,400 --> 00:10:04,400 _ID und die ID dieses Benutzers, 127 00:10:04,400 --> 00:10:09,380 werde ich dies dem Autorenfeld aus dem Kommentar zuweisen. 128 00:10:09,380 --> 00:10:13,880 Nun, wenn der Kommentar eingeht, 129 00:10:13,880 --> 00:10:17,355 enthält der Kommentar im Text der Anforderungsnachricht nur das Bewertungsfeld und das Kommentarfeld. 130 00:10:17,355 --> 00:10:23,425 Jetzt wollen wir das Autorenfeld nicht mehr explizit von der Client-Seite senden, 131 00:10:23,425 --> 00:10:26,090 stattdessen sollte das automatisch 132 00:10:26,090 --> 00:10:28,990 auf der Serverseite basierend auf der Authentizität des 133 00:10:28,990 --> 00:10:32,180 Benutzers eingefügt werden Das ist der Punkt, den ich 134 00:10:32,180 --> 00:10:36,830 in dieser Modifikation wiederholt habe, die ich hier gemacht habe. 135 00:10:36,830 --> 00:10:43,400 So, dass Benutzerinformationen automatisch von dem req.user abgerufen werden, 136 00:10:43,400 --> 00:10:50,200 der in den Text der Anforderungsnachricht vom authentifizierenden Benutzer geladen 137 00:10:50,200 --> 00:10:55,250 wird, der Passport authentifizieren mit der JWT-Strategie dort verwenden wird. 138 00:10:55,250 --> 00:10:59,795 Darüber hinaus 139 00:10:59,795 --> 00:11:03,695 müssen wir jetzt, wenn wir das aktualisierte Gericht hier erhalten, die Informationen des Autors in das Gericht füllen. 140 00:11:03,695 --> 00:11:05,500 Also, an dieser Stelle, 141 00:11:05,500 --> 00:11:08,675 wenn wir das Gericht hier erhalten, 142 00:11:08,675 --> 00:11:15,370 werden wir dann die Gerichte hier durchsuchen. 143 00:11:15,370 --> 00:11:20,150 Also, wir sagen dishes.FindById 144 00:11:21,000 --> 00:11:28,090 und geben Sie dann die Schüssel ID als Parameter hier, 145 00:11:28,090 --> 00:11:30,190 so dass wir sagen, finden Sie nach 146 00:11:30,190 --> 00:11:33,175 ID, Gericht ID, und dann, 147 00:11:33,175 --> 00:11:43,405 wir müssen die Kommentare Autor hier füllen, 148 00:11:43,405 --> 00:11:55,600 und dann sagen wir dann Gericht. 149 00:11:55,600 --> 00:12:04,370 Dort drinnen schicken wir diese Informationen zurück an den Benutzer hier. 150 00:12:04,370 --> 00:12:07,260 Also, lassen Sie mich das ausschneiden und das hier einfügen. 151 00:12:07,260 --> 00:12:12,670 Also, diese Änderung ist erforderlich, weil ich jetzt die 152 00:12:12,670 --> 00:12:15,190 Informationen des Autors wieder in 153 00:12:15,190 --> 00:12:18,760 den Kommentar füllen muss, bevor ich den aktuellen zurück an den Benutzer senden kann. 154 00:12:18,760 --> 00:12:22,220 Also, das ist die zusätzliche Modifikation, die wir 155 00:12:22,220 --> 00:12:26,105 tun müssen, wenn wir die Mongoose-Bevölkerung hier benutzen. 156 00:12:26,105 --> 00:12:29,950 In ähnlicher Weise geht jetzt in den Put, 157 00:12:29,950 --> 00:12:34,450 wenn wir einen bestimmten Kommentar mit der Kommentar-ID ändern, 158 00:12:34,450 --> 00:12:40,830 so dass dies unter dem Gericht ID Kommentare Kommentar ID Teil ist. 159 00:12:40,830 --> 00:12:42,890 Also, wenn wir die setzen hier, 160 00:12:42,890 --> 00:12:49,230 so finden wir zuerst die Gerichte finden durch id req params Gericht ID, 161 00:12:49,230 --> 00:12:50,840 dann in der Schüssel. 162 00:12:50,840 --> 00:12:57,160 Also, das erste, was wir überprüfen, ist sicherzustellen, dass, wenn das Gericht nicht null ist, 163 00:12:57,160 --> 00:13:01,430 und das Gericht Kommentare ID ist nicht null, 164 00:13:01,430 --> 00:13:08,665 so dass wir überprüft, um sicherzustellen, dass der Kommentar tatsächlich in der Schüssel vorhanden ist, 165 00:13:08,665 --> 00:13:12,320 und dann, wenn das Gericht selbst zurückgegeben wird, 166 00:13:12,320 --> 00:13:16,385 dann müssen wir wieder nach 167 00:13:16,385 --> 00:13:21,230 dem Gericht suchen, weil wir müssen die Kommentare Autor in das Gericht füllen. 168 00:13:21,230 --> 00:13:27,950 Also hier, wir sagen dishes.findById (dish ID), 169 00:13:31,750 --> 00:13:36,880 der Grund, warum wir eine weitere Suche machen 170 00:13:36,880 --> 00:13:42,240 müssen, ist, weil wir die comments.author hier füllen müssen, 171 00:13:42,240 --> 00:13:46,355 also das ist der einzige Grund, warum wir hier eine weitere Suche durchführen müssen. 172 00:13:46,355 --> 00:13:50,720 Dann, wenn wir das Gericht hier erhalten, 173 00:13:52,260 --> 00:13:57,700 offensichtlich, weil wir gerade das Gericht aktualisiert haben, so dass die Teller Informationen 174 00:13:57,700 --> 00:14:03,640 in der Datenbank gefunden werden sollten, 175 00:14:03,640 --> 00:14:07,490 so dass sollte gut funktionieren und dann im Inneren gibt es 176 00:14:07,490 --> 00:14:12,215 Risikostatus-Code sagen 200 res setzen Header Inhaltstyp Anwendung json, 177 00:14:12,215 --> 00:14:14,960 und dann das Gericht hier, 178 00:14:14,960 --> 00:14:16,740 und dann werden wir Fehler hier behandeln, 179 00:14:16,740 --> 00:14:19,630 und dann die anderen, wenn die Gerichte 180 00:14:19,630 --> 00:14:24,095 jetzt und auch die anderen Fehler, die wir früher eingerichtet haben, 181 00:14:24,095 --> 00:14:27,050 werden sie wie gewohnt hier behandelt werden. 182 00:14:27,050 --> 00:14:32,790 Also, dies sind die zusätzlichen Änderungen, die wir sicherstellen müssen, wenn Sie das Gericht aktualisieren, 183 00:14:32,790 --> 00:14:39,175 wenn Sie den aktualisierten Kommentar oder das aktualisierte Gericht zurücksenden, 184 00:14:39,175 --> 00:14:44,485 dann werden wir den Kommentar in der Schüssel hier füllen. 185 00:14:44,485 --> 00:14:48,160 In ähnlicher Weise gehen wir zum Löschen hier, 186 00:14:48,160 --> 00:14:50,575 und dann nach dem Löschen des Kommentars, 187 00:14:50,575 --> 00:14:59,310 wieder werden wir das Gericht holen und die Autoreninformationen füllen. 188 00:14:59,310 --> 00:15:01,275 Also, lassen Sie mich einfach diesen Teil kopieren, 189 00:15:01,275 --> 00:15:04,130 und dann werden wir genau das gleiche hier tun, 190 00:15:04,130 --> 00:15:06,770 also sagen wir Gericht speichern, 191 00:15:06,770 --> 00:15:16,210 dann werden wir dann überprüfen dish.FindById (Dish Autor), 192 00:15:16,210 --> 00:15:19,760 und dann werden wir die Kommentare Autor füllen, 193 00:15:19,760 --> 00:15:21,925 und dann sagen wir (dann) Gericht, 194 00:15:21,925 --> 00:15:24,920 und dann res.StatusCode, und so weiter, 195 00:15:24,920 --> 00:15:29,350 und die verbleibende Fehlerbehandlung genau wie zuvor hier. 196 00:15:29,350 --> 00:15:33,040 Also, mit dieser Änderung an den Dish Router, 197 00:15:33,040 --> 00:15:41,420 jetzt der letzte Punkt, den wir berücksichtigen müssen, ist die Tatsache, dass 198 00:15:41,420 --> 00:15:43,740 wir in der Datei user.js jetzt in Felder hinzugefügt haben, 199 00:15:43,740 --> 00:15:49,050 das Feld Vorname und Nachname, das standardmäßig leere Strings sein wird. 200 00:15:49,050 --> 00:15:51,880 Wenn sich der Benutzer registriert, 201 00:15:51,880 --> 00:15:54,670 sollten wir dem Benutzer erlauben, den Vor- und 202 00:15:54,670 --> 00:15:58,040 Nachnamen im Registrierungsprozess anzugeben. 203 00:15:58,040 --> 00:16:00,040 Nun, wo findet das statt? 204 00:16:00,040 --> 00:16:03,025 Das findet in der s.js des Benutzers statt. 205 00:16:03,025 --> 00:16:05,390 Also, zu Benutzern users.js zu gehen, 206 00:16:05,390 --> 00:16:09,885 wenn der Benutzer auf den Schrägstrich Anmeldung postet, 207 00:16:09,885 --> 00:16:13,050 früher haben wir nur den Benutzernamen und das Passwort gepostet. 208 00:16:13,050 --> 00:16:15,105 Zusätzlich zu diesen beiden können wir 209 00:16:15,105 --> 00:16:21,785 in dem JSON-Objekt, das wir in den Text der Anforderungsnachricht einschließen, 210 00:16:21,785 --> 00:16:25,530 die von der Clientseite eingehende Post Request Nachricht, 211 00:16:25,530 --> 00:16:29,590 auch den Vor- und Nachnamen für den Benutzer einschließen. 212 00:16:29,590 --> 00:16:33,740 Also, wenn der Vorname und Nachname für den Benutzer enthalten sind, 213 00:16:33,740 --> 00:16:35,590 was also werde ich hier tun? 214 00:16:35,590 --> 00:16:42,450 Also, erinnern Sie sich, dass, wenn Sie sagen, user.register an dieser Stelle die Benutzerinformationen kommen, 215 00:16:42,450 --> 00:16:45,785 und dann haben Sie den Benutzernamen hier eingereicht, 216 00:16:45,785 --> 00:16:49,460 und Sie haben auch das Passwort hier zugewiesen, das 217 00:16:49,460 --> 00:16:53,380 in den Hash und Salz durch den Pass lokalen Mungo verwandelt wird. 218 00:16:53,380 --> 00:17:00,000 Nun, wenn es keinen Fehler gibt, bedeutet das, dass die Registrierung des Benutzers erfolgreich war, 219 00:17:00,000 --> 00:17:08,740 und so an diesem Punkt, was wir tun werden, werden wir sagen, wenn req.body. 220 00:17:08,740 --> 00:17:13,420 Vorname. Also, was bedeutet, dass der Körper der eingehenden Anforderungsnachricht, 221 00:17:13,420 --> 00:17:16,345 wenn es den Vornamen enthält, 222 00:17:16,345 --> 00:17:24,770 dann sagen wir user.firstname gleich req.body.firstname ist. 223 00:17:26,160 --> 00:17:29,675 In ähnlicher Weise auch für den Nachnamen. 224 00:17:29,675 --> 00:17:32,040 An dieser Stelle 225 00:17:32,040 --> 00:17:34,780 würden wir den Benutzer hier zur Verfügung haben. 226 00:17:34,780 --> 00:17:40,125 Sehen Sie, dass der Benutzer als zweiter Parameter für diese Callback-Funktion hier eintrifft. 227 00:17:40,125 --> 00:17:43,455 Also, wir richten den Vornamen durch Ändern 228 00:17:43,455 --> 00:17:51,490 der Vornamen-Eigenschaft innerhalb des Benutzerdokuments hier sagen, req.body.firstname. 229 00:17:51,490 --> 00:17:55,395 Wenn es existiert, setzen wir den Vornamen des Benutzers auf diesen. 230 00:17:55,395 --> 00:18:03,220 Ebenso, wenn der req.body.nachname verfügbar ist, 231 00:18:03,220 --> 00:18:09,630 so werden wir auch den Nachnamen des Benutzers als req.body.lastname aktualisieren. 232 00:18:09,770 --> 00:18:16,650 Und sobald wir diese beiden Änderungen an dem Vornamen und dem Nachnamen vorgenommen 233 00:18:16,650 --> 00:18:23,160 haben, müssen wir die Änderung speichern, die wir dem Benutzer vorgenommen haben. 234 00:18:23,160 --> 00:18:25,030 Also, wir haben gerade den Benutzer aktualisiert. 235 00:18:25,030 --> 00:18:30,550 Also, wir sagen user.save dann wird dies 236 00:18:30,550 --> 00:18:37,190 den Fehler oder den Benutzer zurückgeben. 237 00:18:37,190 --> 00:18:41,025 Also, wenn die Änderung richtig gespeichert wurde, 238 00:18:41,025 --> 00:18:43,765 dann wird es den Fehler zurückgeben, 239 00:18:43,765 --> 00:18:49,380 sonst wird es den Benutzerwert zurückgeben und dieser Pass authentifizieren wir 240 00:18:49,380 --> 00:18:55,710 es in diesem Benutzer hier tun. 241 00:18:55,710 --> 00:19:00,505 Also, wir werden sagen, user.save (irr, user). 242 00:19:00,505 --> 00:19:04,740 Und dann müssen wir auch eine Kreuzprüfung durchführen, um sicherzustellen, dass, 243 00:19:04,740 --> 00:19:10,660 wenn es einen Fehler beim Speichern der Änderungen für den Benutzer gibt, 244 00:19:10,660 --> 00:19:15,180 wir den Res-Statuscode 500 sagen, 245 00:19:15,180 --> 00:19:18,485 also lassen Sie mich das von dort kopieren. 246 00:19:18,485 --> 00:19:23,275 Also, wir sagen res Statuscode 500, 247 00:19:23,275 --> 00:19:30,220 res setzen Header Inhaltstyp Anwendung json und res.jason hier. 248 00:19:30,220 --> 00:19:35,995 Dann, und wir werden zu diesem Punkt zurückkehren. 249 00:19:35,995 --> 00:19:37,960 Wenn es keinen Fehler gibt, 250 00:19:37,960 --> 00:19:40,480 dann natürlich authentifizieren Sie den Benutzer, indem Sie 251 00:19:40,480 --> 00:19:43,550 Pass authentifizieren mit dem lokalen anrufen, um sicherzustellen, dass 252 00:19:43,550 --> 00:19:48,835 die Benutzerregistrierung erfolgreich war und dies 253 00:19:48,835 --> 00:19:56,390 korrekt durchgeführt werden sollte und in diesem Fall werden Sie diese Nachricht zurück an die Client-Seite. 254 00:19:56,390 --> 00:20:03,215 Wir müssen diesen user.save hier schließen. Stellen Sie 255 00:20:03,215 --> 00:20:07,520 also sicher, dass Sie diesen Endpunkt korrekt schließen. 256 00:20:07,520 --> 00:20:11,005 Also, user.save ist hier geschlossen, und das war's. 257 00:20:11,005 --> 00:20:14,730 Dies sind die Änderungen, die wir für den Benutzer vornehmen müssen. 258 00:20:14,730 --> 00:20:21,740 So, nachdem der Benutzer mit dem angegebenen Benutzernamen und dem angegebenen Passwort registriert wurde, 259 00:20:21,740 --> 00:20:24,940 dann, nachdem der Benutzer erfolgreich registriert wurde, 260 00:20:24,940 --> 00:20:28,235 dann werden wir das Feld Vorname und Nachname 261 00:20:28,235 --> 00:20:32,925 des Benutzerdokuments setzen, indem wir diese beiden hier verwenden. 262 00:20:32,925 --> 00:20:35,900 Wir möchten sicherstellen, dass der Benutzer erfolgreich 263 00:20:35,900 --> 00:20:39,160 registriert ist, bevor wir dafür den Vor- und Nachnamen gesendet haben. 264 00:20:39,160 --> 00:20:42,540 Deshalb führen wir diesen Vorgang durch, nachdem der Benutzer 265 00:20:42,540 --> 00:20:46,360 erfolgreich registriert wurde. Das war's. 266 00:20:46,360 --> 00:20:53,785 Lassen Sie uns die Änderungen speichern und gehen und überprüfen Sie den Server. 267 00:20:53,785 --> 00:20:56,185 Nachdem Sie die Änderungen gespeichert haben, 268 00:20:56,185 --> 00:20:59,980 gehen wir nun zum Terminal und 269 00:20:59,980 --> 00:21:06,925 dann, bevor ich den Server starte, 270 00:21:06,925 --> 00:21:16,690 lassen Sie mich zuerst meine MongoDB überprüfen und den Benutzer löschen, den wir zuvor registriert haben. 271 00:21:16,690 --> 00:21:25,640 Also, wir werden sagen, verwenden Sie Verwirrung und dann sagen wir db.usersfind. 272 00:21:25,650 --> 00:21:30,690 Wir wissen also, dass dieser bestimmte Benutzer früher registriert wurde, 273 00:21:30,690 --> 00:21:32,580 aber wenn wir diesen Benutzer registrieren, 274 00:21:32,580 --> 00:21:35,700 haben wir nicht den Vor- und Nachnamen für den Benutzer registriert. 275 00:21:35,700 --> 00:21:39,155 Also werde ich diesen Benutzer löschen und dann den Benutzer erneut registrieren. 276 00:21:39,155 --> 00:21:48,370 Also, um das mit der Mongo-Welligkeit zu tun, werde ich sagen, dass db-Benutzer fallen, 277 00:21:48,370 --> 00:21:52,220 und dann sagen wir, 278 00:21:52,220 --> 00:21:54,620 dass db-Benutzer finden, und das sollte eine leere zurückgeben. 279 00:21:54,620 --> 00:22:01,685 Keine Benutzer registriert dort und dann verlassen wir die Mongo-Welligkeit. 280 00:22:01,685 --> 00:22:05,285 Und so, sobald wir diesen registrierten Benutzer entfernt haben 281 00:22:05,285 --> 00:22:08,760 , dann lassen Sie mich meinen Server starten. 282 00:22:09,490 --> 00:22:12,275 Und sobald der Server betriebsbereit ist, 283 00:22:12,275 --> 00:22:16,240 gehen wir zu Postman und registrieren Sie dann 284 00:22:16,240 --> 00:22:20,930 einen neuen Benutzer zusammen mit dem Vor- und Nachnamen des Benutzers. 285 00:22:20,930 --> 00:22:26,845 Dann werden sie sich als dieser Benutzer anmelden und dann schauen wir uns an, wie 286 00:22:26,845 --> 00:22:31,650 die Mongoose-Bevölkerung uns hilft, die Informationen über 287 00:22:31,650 --> 00:22:37,000 den Benutzer automatisch in das Dokument dort zu füllen. 288 00:22:37,000 --> 00:22:40,029 Jetzt gehen Sie zu Postman, 289 00:22:40,029 --> 00:22:42,660 lassen Sie mich eine Anmeldung für einen neuen Benutzer. 290 00:22:42,660 --> 00:22:48,310 Also, ich mache einen Beitrag localhost: 3000 Benutzer melden sich an. 291 00:22:48,310 --> 00:22:50,715 Im Nachrichtentext 292 00:22:50,715 --> 00:22:54,910 hatten wir den Benutzernamen und das Passwort bereits drin. 293 00:22:54,910 --> 00:22:59,199 Lassen Sie mich zwei zusätzliche Felder hinzufügen: 294 00:22:59,199 --> 00:23:09,350 Vorname, Nachname. 295 00:23:14,880 --> 00:23:18,530 Registrieren Sie dann diesen Benutzer. 296 00:23:20,850 --> 00:23:23,680 Sobald ich den Benutzer registriert habe, 297 00:23:23,680 --> 00:23:26,350 können Sie sehen, dass die Registrierung erfolgreich war. 298 00:23:26,350 --> 00:23:29,810 Lassen Sie mich nun als dieser Benutzer einloggen. 299 00:23:29,820 --> 00:23:32,640 Also, um sich als Benutzer anzumelden, 300 00:23:32,640 --> 00:23:37,620 lassen Sie mich einen Beitrag machen und überprüfen, um sicherzustellen, dass. 301 00:23:37,620 --> 00:23:40,475 Also, ich mache einen Beitrag zum Anmelden von Benutzern. 302 00:23:40,475 --> 00:23:45,725 Lassen Sie mich überprüfen und ich sehe, dass der Benutzername und das Passwort korrekt eingegeben sind. 303 00:23:45,725 --> 00:23:47,775 Also, wenn ich mich einlogge, 304 00:23:47,775 --> 00:23:53,165 sollte ich erfolgreich eingeloggt sein und ich sollte in der Lage sein, dieses Token dort zu erhalten. 305 00:23:53,165 --> 00:24:02,660 Denn dieses Token ist wichtig für uns, um in einer Schüssel zu unserer Server-Site hinzufügen zu können. 306 00:24:02,660 --> 00:24:05,915 Nachdem Sie das Token erhalten haben, 307 00:24:05,915 --> 00:24:10,250 kopieren Sie diese Token-Zeichenfolge und speichern Sie sie, da Sie dies im 308 00:24:10,250 --> 00:24:13,220 Autorisierungs-Header für die 309 00:24:13,220 --> 00:24:16,910 Post-Put- und Löschvorgänge benötigen, die Sie später ausführen werden. 310 00:24:16,910 --> 00:24:20,540 Also lassen Sie mich das Token kopieren. 311 00:24:20,540 --> 00:24:23,890 Nun, normalerweise würde ich diese Token behalten, ist, 312 00:24:23,890 --> 00:24:28,400 dass ich einfach ein Textdokument öffne und es dann kopieren und in das Textdokument einfügen werde. 313 00:24:28,400 --> 00:24:31,190 Damit 314 00:24:31,190 --> 00:24:34,230 ich für nachfolgende Postman-Anfragen diese Zeichenfolge einfach kopieren und sie dann bei 315 00:24:34,230 --> 00:24:37,770 Bedarf in den Autorisierungs-Header einfügen kann. 316 00:24:37,770 --> 00:24:44,070 Also, lassen Sie mich das Token kopieren und hier habe ich ein Textdokument geöffnet. 317 00:24:44,070 --> 00:24:50,815 Also, ich werde diese Zeichenfolge in dieses Textdokument einfügen. 318 00:24:50,815 --> 00:24:57,170 Also, hier haben wir das Token, das wir erhalten haben. 319 00:24:57,170 --> 00:25:03,120 Lassen Sie uns jetzt gehen und ein Gericht auf unserem Server posten. 320 00:25:03,120 --> 00:25:05,135 Zurück zum Postboten, 321 00:25:05,135 --> 00:25:07,535 lassen Sie mich ein Gericht auf dem Server posten. 322 00:25:07,535 --> 00:25:12,690 Also, hier werde ich den Beitrag hier wählen. 323 00:25:12,690 --> 00:25:21,334 Drinnen hier habe ich die Dish-Informationen, die ich früher verwendet hatte, aber für die Kommentare 324 00:25:21,334 --> 00:25:25,345 , jetzt, daran erinnern, dass wir früher Autorenfeld hatten, das eine Zeichenfolge speicherte. 325 00:25:25,345 --> 00:25:28,770 Also, alle diese Kommentare sind nicht gültig. 326 00:25:28,770 --> 00:25:35,110 Also werde ich alle diese Kommentare aus der Einreichung löschen, weil 327 00:25:35,110 --> 00:25:42,570 wir jetzt erwarten, dass der Benutzer selbst Kommentare posten wird. 328 00:25:42,570 --> 00:25:44,460 Wenn der Benutzer Kommentare eingibt, 329 00:25:44,460 --> 00:25:52,155 fügen wir automatisch die ID des Benutzers in das Autorenfeld der Kommentare hinzu. 330 00:25:52,155 --> 00:25:55,390 Also, lassen Sie mich dieses Gericht hier posten. 331 00:25:55,390 --> 00:25:57,325 Gehe zum Header, 332 00:25:57,325 --> 00:26:01,550 in der Autorisierungs-Header, werde ich sagen, 333 00:26:02,310 --> 00:26:12,785 Bearer und dann, fügen Sie das Token ein und senden Sie es dann. 334 00:26:12,785 --> 00:26:17,055 Ich sollte einen Beitrag dazu machen. 335 00:26:17,055 --> 00:26:21,950 Also, ich werde Post sagen und so, wenn ich jetzt poste, 336 00:26:21,950 --> 00:26:26,785 sehen Sie, dass dieses Gericht auf der Serverseite veröffentlicht wurde, 337 00:26:26,785 --> 00:26:31,340 und mit dem Kommentarfeld in diesem Moment leer ist. 338 00:26:31,340 --> 00:26:34,450 Also, nachdem ich dieses Gericht gepostet habe, 339 00:26:34,450 --> 00:26:37,660 lassen Sie mich die ID dieses Gerichts kopieren. 340 00:26:37,660 --> 00:26:40,835 Also, lassen Sie mich diese ID für das Gericht kopieren, weil ich 341 00:26:40,835 --> 00:26:44,735 das brauchen, um Kommentare für dieses Gericht zu posten. 342 00:26:44,735 --> 00:26:47,075 Dann gehe ich zu meinem Texteditor, 343 00:26:47,075 --> 00:26:51,485 ich werde die ID des Gerichts hier speichern. 344 00:26:51,485 --> 00:26:54,550 Nun, natürlich, sobald Sie Ihre Client-Seite erstellt haben, 345 00:26:54,550 --> 00:26:57,770 wird Ihr Client automatisch alle diese Informationen haben. 346 00:26:57,770 --> 00:27:02,565 So wird Ihr Client automatisch in der Lage sein, das Token zu senden und so weiter. 347 00:27:02,565 --> 00:27:06,385 Also, Sie müssen diese Ausschneiden und Einfügen Sache nicht tun, aber mit Postboten 348 00:27:06,385 --> 00:27:11,750 ist dies die einzige Möglichkeit, dass wir alle Informationen zu unseren Postboten hinzufügen können, 349 00:27:11,750 --> 00:27:17,185 die vom Postboten auf den Server gehen. 350 00:27:17,185 --> 00:27:22,090 Nun, um uns zu überzeugen, dass dieses Gericht tatsächlich existiert, 351 00:27:22,090 --> 00:27:26,310 lassen Sie mich ein get auf der lokalen Hostcolon:3000/Gerichte. 352 00:27:26,570 --> 00:27:30,750 Wenn ich ein get mache, können Sie tatsächlich sehen, dass 353 00:27:30,750 --> 00:27:34,175 dieses spezielle Gericht auf der Serverseite existiert. 354 00:27:34,175 --> 00:27:37,600 Also, lasst uns jetzt versuchen, einen Kommentar zu posten. 355 00:27:37,600 --> 00:27:39,515 Also, um einen Kommentar zu posten, 356 00:27:39,515 --> 00:27:45,550 lassen Sie uns einen Beitrag machen und wir werden sagen, 357 00:27:49,940 --> 00:27:54,950 localhost: 3000/Gerichte, Schrägstrich und die ID des Gerichts, das 358 00:27:54,950 --> 00:27:59,910 ich gerade kopiert habe, und Schrägstrich Kommentare. 359 00:27:59,910 --> 00:28:03,090 Wenn Sie auf die Kommentare posten, 360 00:28:03,090 --> 00:28:11,285 müssen Sie sicherstellen, dass wir im Körper den Kommentar hier hinzufügen werden. 361 00:28:11,285 --> 00:28:13,605 Also, ein typischer Kommentar enthält 362 00:28:13,605 --> 00:28:20,555 eine Bewertung von sagen 363 00:28:20,555 --> 00:28:26,140 fünf und dann Kommentar. 364 00:28:29,030 --> 00:28:33,535 Also, lassen Sie mich einfach einen zufälligen Kommentar eingeben, 365 00:28:33,535 --> 00:28:34,915 nur um Ihnen zu zeigen. 366 00:28:34,915 --> 00:28:41,085 Also, dies sollte im Körper des Beitrags für die Kommentare sein und in der Kopfzeile 367 00:28:41,085 --> 00:28:44,665 sollten wir den Autorisierungs-Header hinzufügen. 368 00:28:44,665 --> 00:28:50,525 Also, für den Autorisierungs-Header, sagen wir, Träger. 369 00:28:50,525 --> 00:28:54,875 Ich muss das Token hier einfügen und 370 00:28:54,875 --> 00:28:59,065 den Token-Wert einfügen, den ich früher gespeichert habe. 371 00:28:59,065 --> 00:29:02,575 Lassen Sie uns jetzt diesen Kommentar posten. 372 00:29:02,575 --> 00:29:05,265 Dann, wenn der Kommentar veröffentlicht wird, 373 00:29:05,265 --> 00:29:07,705 schauen wir uns den zurückgegebenen Wert hier an. 374 00:29:07,705 --> 00:29:09,510 Wenn Sie also nach unten blättern, 375 00:29:09,510 --> 00:29:14,975 können Sie sehen, dass das Gericht, zu dem der Kommentar hinzugefügt wurde, zurückgegeben wurde. 376 00:29:14,975 --> 00:29:19,300 Beachten Sie, dass die Teller Informationen vorhanden sind, aber beachten Sie insbesondere, 377 00:29:19,300 --> 00:29:22,620 was in dem Kommentar enthalten ist, der hier gepostet wurde. 378 00:29:22,620 --> 00:29:25,740 Wie Sie sehen können, wissen Sie bereits, dass die aktualisierten und 379 00:29:25,740 --> 00:29:29,050 erstellten Felder automatisch von Mungo hinzugefügt werden. 380 00:29:29,050 --> 00:29:31,900 Die Bewertung und der Kommentar, den wir eingereicht haben, sind 381 00:29:31,900 --> 00:29:34,780 genau da, aber beachten Sie, wie das Autorenfeld 382 00:29:34,780 --> 00:29:40,675 jetzt die ID enthält, die dem Benutzer entspricht. 383 00:29:40,675 --> 00:29:47,190 Nun, wie wir im Code gesehen haben, wie der Autor Feld-Informationen hinzugefügt wird, jetzt, 384 00:29:47,190 --> 00:29:49,965 wenn Sie ein bekommen auf dem Geschirr, 385 00:29:49,965 --> 00:29:52,900 Sie werden feststellen, dass dieses Feld Autor 386 00:29:52,900 --> 00:29:56,890 automatisch von den Benutzerinformationen hier ausgefüllt werden. 387 00:29:56,890 --> 00:30:02,180 Also, lassen Sie uns jetzt ein get auf dem localhost: 3000/Gerichte. 388 00:30:02,300 --> 00:30:06,820 Also, wenn wir jetzt ein get auf diesen Punkt, 389 00:30:06,820 --> 00:30:12,215 Sie werden jetzt feststellen, dass in den Gerichten hier, 390 00:30:12,215 --> 00:30:15,460 genau dort, die Informationen über das Gericht bereits 391 00:30:15,460 --> 00:30:20,110 vorhanden ist, aber beachten Sie, wie der Kommentar jetzt konstruiert ist. 392 00:30:20,110 --> 00:30:23,500 Der Kommentar enthält nun, 393 00:30:23,500 --> 00:30:27,240 die Bewertungskommentarfelder, wie wir zuvor gesehen haben, 394 00:30:27,240 --> 00:30:28,780 die aktualisierte und erstellte bei, 395 00:30:28,780 --> 00:30:32,910 aber beachten Sie, was mit dem Autorenfeld hier passiert ist. 396 00:30:32,910 --> 00:30:36,890 Wenn Sie also eine get-Anfrage ausführen, weil wir eine Auffüllung auf 397 00:30:36,890 --> 00:30:42,230 der Serverseite durchgeführt haben, wenn der get-Vorgang aufgerufen wird, 398 00:30:42,230 --> 00:30:45,750 hat das Populate 399 00:30:45,750 --> 00:30:51,390 die Autoreninformationen automatisch in die Position im Autorenfeld hier aufgefüllt. 400 00:30:51,390 --> 00:30:54,215 Dort können Sie also sehen, dass Sie vom Autor aus den 401 00:30:54,215 --> 00:30:56,260 Nachnamen und die 402 00:30:56,260 --> 00:30:58,970 Vornameninformationen automatisch aus dem Autorenfeld nachschlagen können. 403 00:30:58,970 --> 00:31:01,645 Wenn Sie also einen Kommentar erstellen müssen, 404 00:31:01,645 --> 00:31:04,050 haben Sie jetzt die Bewertung, 405 00:31:04,050 --> 00:31:08,210 den Kommentar und auch den Vor- und Nachnamen 406 00:31:08,210 --> 00:31:12,485 des Autors automatisch in dieses Dokument aufgenommen. 407 00:31:12,485 --> 00:31:15,645 Außerdem ist der Benutzername in diesem Dokument enthalten. 408 00:31:15,645 --> 00:31:21,495 Auf diese Weise können Sie Informationen aus einem anderen Dokument hinzufügen und 409 00:31:21,495 --> 00:31:27,905 ein zweites Dokument mit diesen Informationen füllen, bevor Sie von der Serversite aus antworten. 410 00:31:27,905 --> 00:31:32,315 Dies ist also die Verwendung von Mungo Population und wie wir 411 00:31:32,315 --> 00:31:37,580 Informationen automatisch in ein Mungo Dokument füllen können. 412 00:31:37,580 --> 00:31:41,280 Damit schließen wir diese Übung ab. 413 00:31:41,280 --> 00:31:46,075 In dieser Übung haben wir die Verwendung von Mungo Population gesehen und wir haben auch gesehen, 414 00:31:46,075 --> 00:31:51,785 wie wir Informationen von einem Dokument in ein anderes Dokument auffüllen können. 415 00:31:51,785 --> 00:31:57,340 Wenn wir den Server so modifizieren, dass er die Bevölkerung für die Anfragen erledigt, 416 00:31:57,340 --> 00:32:02,200 kümmert sich Mungo automatisch darum, diese Informationen für uns zu füllen. 417 00:32:02,200 --> 00:32:04,190 Alles, was wir tun müssen, 418 00:32:04,190 --> 00:32:10,900 ist, den Verweis auf das andere Dokument in Form der Objekt-ID 419 00:32:10,900 --> 00:32:16,240 in dem Dokument zu speichern, in das Sie diese Informationen füllen möchten. 420 00:32:16,240 --> 00:32:18,965 Damit schließen wir diese Übung ab. 421 00:32:18,965 --> 00:32:25,230 Dies ist ein guter Zeitpunkt für Sie, ein Git-Commit mit der Nachricht zu machen, Mungo Population.