HDA_with_Cpp
1.0.0
Dieses Repository enthält eine HDA basierend auf HTMX (Frontend) und Drogon C ++ Framework (Backend).
Ziel war es, eine reaktionsschnelle "Web -App" zu erstellen, ohne die üblichen JavaScript -Frameworks zu verwenden.
Die Idee für dieses Projekt kam beim Lesen des hervorragenden Buches Hypermedia Systems. Darin sprechen die Autoren über alternative Möglichkeiten zum Schreiben modern Webanwendungen. Im Gegensatz zu den meisten anderen Büchern in der Webentwicklung verlassen sich die Autoren nicht auf ein JavaScript -Framework, sondern kehren zu den Wurzeln der Hypermedia -Architektur zurück, die the web selbst ist.
Ich habe auch einen Artikel über dieses Projekt und meine allgemeine Motivation geschrieben, HTMX und C ++ zu verwenden.
Anstatt JavaScript zu verwenden, um HTML zu überwinden , eine Strategie, die sich im Grunde genommen um dicke Klientinnen der 90ES reproduziert, verwenden die Autoren htmx , um es zu erweitern . Sie machen es in der Lage, mehr zu tun, ohne auf clevere JavaScript -Tricks zurückzufallen. Natürlich ist JS nicht verboten und htmx selbst ist für seine eigene Entwicklung darauf angewiesen, aber JS ist nicht sichtbar, da es keinen tatsächlichen Bedarf daran gibt.
Wir müssen JS nicht verwenden, um scheinbar "unzureichende" Hypermedia -Kontrollen zu ersetzen, da HTMX hier ist, um sie zu erweitern. Es macht sie in der Lage, als ursprünglich definiert mehr zu tun. Ein Anker -Tag ( <a> ) kann beispielsweise "aktualisiert" werden, damit er Anforderungen an die Post-, Put-, Patch- oder sogar Löschen von Anforderungen ausführen kann. Ein <form> Tag muss nicht die einzige Hypermedia -Steuerung für das Senden von Daten per Postanfragen sein. Wie wäre es, wenn Sie Ihre eigenen Steuerelemente schreiben, die genau das Gleiche tun können? Oder vielleicht <form> , mit denen vorhandene Einträge auf dem Server gepatscht werden können? Was normalerweise explizite JS -Code erfordert, kann jetzt mit verbesserten Hypermedia -Kontrollen deklarativ durchgeführt werden.
Hier ist ein Beispiel aus diesem Projekt. Zwei Schaltflächen ( abbrechen und speichern ), die in fast jeder ausreichend komplexen Web -App zu finden sind.
< button hx-get =" /contacts "
hx-target =" #main "
hx-swap =" innerHTML " >
Cancel
</ button >
< button hx-post =" /contacts/{%contact.ID%}/edit "
hx-include =" input "
hx-target =" #main "
hx-swap =" innerHTML " >
Save
</ button >Ob Sie es glauben oder nicht, aber diese beiden verwenden die folgenden Funktionen:
<button> Steuerelemente verfügbar sind.Und keine einzige Zeile von JavaScript wurde benötigt, damit es funktioniert. So leistungsstarke Hypermedia -Architektur ist tatsächlich.
Wir verwenden auch _hyperscript, eine kleine Bibliothek für die Ereignisbehandlung und DOM -Manipulation. Damit können wir Ereignisse anhören und versenden, DOM -Objekte manipulieren, alle, ohne HTML zu verlassen.
Hier ist ein Beispiel aus diesem Projekt:
< button id =" edit-c " class =" btn btn-primary "
hx-get =" /contacts/{%c.ID%}/edit "
hx-target =" #main "
hx-swap =" innerHTML " > Edit </ button >
< button class =" btn btn-danger "
hx-delete =" /contacts/{%c.ID%}/delete "
hx-confirm =" Are you sure you wish to delete this contact? "
hx-target =" this "
hx-swap =" none "
_ =" on click remove #edit-c
then remove me "
> Delete </ button >
< button class =" btn btn-info "
hx-get =" /contacts "
hx-target =" #main "
hx-swap =" innerHTML " > Back </ button > Im zweiten <button> Steuerelement haben wir einige Teile von _hyperscript, die Folgendes ausführen:
Das Endergebnis ist das Entfernen der Schaltflächen Edit und Delete . Nur der Button Back bleibt.
Anstatt Jsons hin und her zu senden ( und jedes Mal, wenn sie nach einer internen Logik analysiert werden ), können wir HTML wie ursprünglich entworfen: als Fahrzeug für aussagekräftige Hypermedia -Anwendungen. Das HTTP -Protokoll existiert aufgrund von HTML, aber heutzutage übertragen wir JSON meistens darüber. Dies macht tatsächlich wenig Sinn, da JSON die Anwendungssemantik nicht transportieren kann, was die ursprüngliche Bedeutung der Archieur der Client-Server des Webs effektiv verkrüppelt. Kein Wunder, dass wir massive JS -Frameworks an unseren Frontenden brauchen, da unsere Server meistens nur Datenanbieter mit JSON -APIs sind. Und JSON APIs sind nicht "erholsam".
Der Beispiel -Backend -Quellcode des Buches ist in Python geschrieben und kann anstelle von C ++ verwendet werden. Tatsächlich habe ich versucht, die ursprüngliche Python -APIs nachzuahmen, so dass es keine großen Lücken beim Verständnis von beiden geben sollte. Ich habe den C ++ - Code geschrieben, als ich die jeweiligen Kapitel las.
Da htmx jedoch sehr agnostisch ist, gibt es kein Problem, eine Sprache zu verwenden, sodass ich C ++ verwendet habe. Dies ist auch aus der Lernperspektive gut, da es mich zwingt, alles zu überprüfen.
Ich denke, dass wir Bloat nicht nur aus unseren Frontenden entfernen sollten [ hier ein massives JS -Framework einlegen ], sondern auch aus unseren Backends [ hier ein massives Backend -Framework eingeben ]. Massive Software verbraucht ein großes Angebot an Zeit und Energie. Menschliche Zeit und Energie sowie CPU -Zyklen und Elektrizität.
Ein paar C ++ - Bibliotheken werden benötigt, damit die Zusammenstellung erfolgreich ist. Dieses Projekt verwendet VCPKG als Paketmanager, aber Sie können stattdessen eine andere auswählen.
Um ein Paket zu installieren, rufen Sie einfach vcpkg install PACKAGE_NAME auf.
Die folgenden Pakete werden benötigt:
drogon
drogon[ctl]
fmt
argparse
brotli
zlib
openssl
sqlite3
soci[core]
soci[sqlite3]
Die Suche nach ihnen ist einfach: vcpkg search PACKAGE_NAME
sudo apt install uuid-dev libcriterion-dev
Windows -Benutzer müssen zuerst die MSYS -Umgebung einrichten. Wählen Sie nach der Installation den MSYS2 MINGW64 -Eintrag im Windows -Startmenü aus. Verwenden Sie den MSYS UCRT4 oder einen anderen Eintrag nicht!
Geben Sie im neu geöffneten Bash -Fenster diesen Befehl ein, um die erforderlichen Pakete zu installieren:
pacman -S git mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake make mingw-w64-x86_64-c-ares mingw-w64-x86_64-jsoncpp mingw-w64-x86_64-openssl
Überprüfen Sie, ob der Compiler verfügbar ist, mit which g++ . Sie sollten eine solche Nachricht sehen:
$ which g++
/mingw64/bin/g++ Sie benötigen auch einen Editor, um die Umgebungswege zu aktualisieren. Installieren Sie daher Ihre bevorzugte, z. B. pacman -Sy nano oder pacman -Sy vim
Öffnen Sie Ihre .bash_profile mit nano .$HOME/.bash_profile und fügen Sie diese drei Zeilen zum Ende der Datei hinzu:
PATH=/mingw64/bin: $PATH
export VCPKG_DEFAULT_TRIPLET=x64-mingw-static
export VCPKG_DEFAULT_HOST_TRIPLET=x64-mingw-static Speichern und schließen Sie die Datei. Laden Sie es neu mit: source $HOME/.bash_profile oder . ~/.bash_profile
Die beiden Tripletteinträge werden später benötigt, um vcpkg zu unterweisen, Mingw anstelle des Standard -Visual C ++ - Compiler zu verwenden. Und da wir auch statische Bibliotheken kompilieren möchten, geben wir sie mit dem static Suffix an.
Im Gegensatz zu anderen Paketen wird Drogon nicht mit vcpkg installiert. Das derzeit verfügbare VCPKG -Paket -THOWS -Kompilierungsfehler, was der Grund ist, warum wir es manuell kompilieren müssen.
Klonen Sie die Drogon -Quellen und bereiten Sie die Bauumgebung vor. Der Pfad /c/bin/drogon aus dem folgenden Beispiel sollte an Ihre lokalen Einstellungen angepasst werden. Das Root dieses Pfades ( /c/bin ) muss einem bereits vorhandenen Pfad im Windows -System, z. B. C:/bin oder einem anderen Pfad Ihrer Auswahl abzubauen.
git clone https://github.com/drogonframework/drogon --recursive
mkdir drogon/build
cd drogon/build
cmake .. -G " MSYS Makefiles " -DCMAKE_INSTALL_PREFIX:PATH=/c/bin/drogon Kompilieren Sie jetzt Drogon mit make -j und warten Sie, bis es abgeschlossen ist.
Installieren Sie Drogon mit make install .
Sie sollten jetzt eine Liste von Ordnern in C:/bin/drogon sehen.
Der zweite Schritt ist die Installation einiger Bibliotheken, die statisch verknüpft werden. Wir werden vcpkg verwenden, um sie alle zu kompilieren.
Geben Sie aus demselben Bash -Fenster die folgenden Befehle an, um vcpkg einzustellen.
cd $HOME
git clone https://github.com/microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.batBeachten:
If you pefer to install vcpkg files under different root path, change the first command "cd $HOME" from the script above.
For example: cd /c/Users/WINDOWS_USER_NAME
In MSYS Bash, the Windows file system is located under /c.
And your MSYS $HOME folder is located under "home" in your Windows MSYS root folder.
Geben Sie im Ordner vcpkg die folgenden Befehle an, um die erforderlichen Bibliotheken zu installieren:
./vcpkg.exe install argparse
./vcpkg.exe install fmt
./vcpkg.exe install brotli
./vcpkg.exe install zlib
./vcpkg.exe install openssl
./vcpkg.exe install sqlite3
./vcpkg.exe install soci
./vcpkg.exe install soci[sqlite3] Jetzt können Sie dieses Projekt über Poweshell mit ./buildall.ps1 kompilieren.
Vergessen Sie jedoch nicht, vcpkg_root in meson.build zu ändern. Dieser Pfad sollte auf das zuvor klonierte vcpkg -Repository zeigen.
Mein Build -System der Wahl ist Meson, da Makefiles schwer zu pflegen sind und ich einfach nicht lernen möchte, wie man CMake benutzt. Das Leben ist für benutzerhostile Software zu kurz.
Es gibt zwei Skripte, buildall.sh (macOS/Linux) und buildall.ps1 (Windows). Mit diesen beiden werden die folgenden Schritte ausgeführt:
builddir ( nur unter Windows, in macOS/Linux, dies wird von Meson durchgeführt )drogon_ctl , um CSPs in C ++ - Quelldateien umzuwandeln und in src/views einzulegensrc zusammenstellenbuilddir einEin C ++ 20 -Compiler wird benötigt. Ich verwende GNU C ++ V12.1.0.
Vor dem Versuch, das Projekt zu erstellen, passen Sie bitte diese beiden Variablen in der Datei meson.build an:
Das triplet enthält die Informationen über den Host-Computer, z. B. x64-osx .
Der vcpkg_root ist der Root -Ordner, der von vcpkg installierte Pakete enthält.
drogon_ctl wird von Meson verwendet, um CSP -Vorlagen in C ++ - Dateien umzuwandeln.
Der Frontend verwendet die HTMX -Bibliothek und einige Bootstrap -Ressourcen für das Styling. Es gibt keinen handgeschriebenen JavaScript, das als HTMX ausgeführt wird, das die responsive Dinge liefert, von denen wir erwarten, dass sie eine modern Web-App anbieten.
Das Backend basiert auf dem sehr schnellen C ++ - Web Framework namens Drogon .
Die verwendete Datenbank ist SQLite3, kann jedoch leicht durch jede andere SQL -Datenbank ersetzt werden. Passen Sie einfach die src/database/db_mgr.cpp -Klasse an. Die Bibliothek für den Zugriff auf SQLite3 ist SOCI und unterstützt viele andere Datenbank -Backends. Das Root dieses Projekts enthält eine SQLite3 -Datei, demo.db , die die App standardmäßig verwendet. Es gibt auch eine CSV -Datei, contacts.csv , die einige Einträge enthält, mit denen eine neue Tabelle gefüllt werden kann.
controllers enthält Klassen, mit denen Drogon Client -Aufrufe zu Funktionen im Backend abbilden.database enthält eine kleine Wrapper -Klasse zum Zugriff auf die SQLite3 -Instanz.dtos enthält Data Transfer Objects , die für Datenkarten zwischen Frontend und Backend verwendet werden.templates enthält CSPs (C ++ - Serverseiten), bei denen es sich um Vorlagen handelt, die drogon_ctl zum Generieren von C ++ - Quellen verwendet. Diese Quellen werden verwendet, um HTML -Ausgänge zu erstellen.views enthält von Drogon-generierte C ++-Klassen. Diese Dateien sollten nicht manuell bearbeitet werden . Sie werden an jedem Build ersetzt. Verwenden Sie stattdessen CSPs aus dem Ordner templates -Ordners, um ihr Verhalten oder Inhalt zu ändern. Tests werden mit der Kriterienbibliothek durchgeführt.
Das Kriterium kann über brew install criterion installiert werden. Andernfalls können Sie es manuell erstellen, wie hier beschrieben.
Um das Kriterium mit Meson aufzubauen, klonen Sie zuerst das Repo:
git clone --recursive https://github.com/Snaipe/Criterion.gitGeben Sie dann die folgenden Befehle aus:
cd Criterion
meson - Dprefix = c: / bin / criterion build
ninja - C build installDas Präfix für das Installationsverzeichnis kann geändert werden. Setzen Sie nach Abschluss der Installation den Pfad in die DLL -Datei des Kriteriums. Diese DLL wird von Test Executables verwendet, die das Kriterium verknüpft haben.
Die Testquellen dieses Projekts befinden sich im test und werden automatisch von Meson erstellt. Um Tests auszuführen, können Sie diese beiden Optionen verwenden:
PS > meson test - C .builddir
ninja: no work to do .
ninja: Entering directory ` .builddir '
ninja: no work to do.
1/1 basic OK 0.09s
Ok: 1
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to .builddirmeson-logstestlog.txtOder indem Sie den Test direkt anrufen:
PS > .builddir test_demo_web_server.exe
[ ==== ] Synthesis: Tested: 1 | Passing: 1 | Failing: 0 | Crashing: 0 Die Webanwendung beginnt mit dem Laden des index.html , der ein div -Tag mit ID = "Main" enthält. In der gesamten App wird dieses Tag von anderen Steuerelementen verwendet, um seinen Inhalt dynamisch zu ersetzen, ohne dass Seiten aktualisiert werden. Im Gegensatz zu anderen typischen modern Web -Apps verwenden wir jedoch keine JS -Frameworks wie React oder Angular, um die App reagieren zu lassen. Stattdessen verwenden wir htmx nur als unsere Skriptbibliothek.
Es sind auch drei bootstrap -Ressourcen beteiligt, aber dies ist, dass die App nur besser aussieht. Bootstrap ist keine Voraussetzung und kann durch eine andere Bibliothek oder eigene Stylesheets ersetzt werden. Gleiches gilt für jQuery , das als Bootstrap -Abhängigkeit enthalten ist. Eine dieser Bibliotheken kann sicher entfernt werden, da sie htmx oder _hyperscript nicht beeinflussen.
Die Web-App kommuniziert mit dem Server in einer Standard-Anfrage-Response-Art und Weise. Aber im Gegensatz zu so vielen anderen Web -Apps wird kein JSON verwendet. Stattdessen sendet der Server nur Teile des HTML -Code, mit dem der Client den aktuellen Status der App aktualisiert.
Das Serverprogramm akzeptiert zwei Parameter zum Einstellen von IP und Port.
Usage: demo_web_server [options]
Optional arguments:
-h --help shows help message and exits [default: false]
-v --version prints version information and exits [default: false]
-i --ip-address Server IP Address [default: " 127.0.0.1 " ]
-p --port Port [default: 3000]
Sie können auch die mitgelieferte Drogon config.json verwenden, um das Verhalten des Servers zu steuern. Da Drogon viele Optionen bietet, sollten Sie sich zunächst damit vertraut machen. Die Konfigurationsdatei in diesem Projekt enthält nur wenige Einstellungen.
Es gibt auch eine separate JSON-basierte Konfigurationsdatei, server_config.json , die vom Webserver verwendet wird. Derzeit definiert es nur den Ort der SQLite3 -Datei, wird jedoch in Zukunft erweitert.
{
"database" : {
"type" : " sqlite3 " ,
"file" : " demo.db "
}
} Diese Datei sollte nicht mit Drogons eigenem JSON verwechselt werden, der als config.json bezeichnet wird.
MIT
