Verzeichnisstruktur in Tntnet-Projekten

Standard

Es macht immer Sinn, sich über die Verzeichnisstruktur seines Codes Gedanken zu machen. Gerade bei größeren Projekten mit Arbeitsteilung, sollte die Arbeitsteilung auch durch die Ordnerstruktur unterstützt werden. Die Verwendung der Namensräume sollte selbstverständlich möglich konform zur Ordnerstruktur sein. Das gelingt mir in der Praxis auch nicht immer 100%, aber es ist sehr hilfreich, wenn man sich in fremden Code einarbeiten muss.

Bei der Ordnerstruktur macht Tntnet dem Entwickler keinerlei Vorschriften, wie diese auszusenden hat. Gerade wenn ein umfangreicher Code nicht umgeschrieben werden muss, wird man das sehr zu schätzen wissen. Ist man aber aber tatsächlich in der komfortablen Situation, ein völlig neues Programm zu schreiben ohne Altlasten, möchte man sich vielleicht doch an einem best practice orientieren. So könnte eine Verzeichnisstruktur aussehen….

/projektname
/projektname
/projektname/src
/projektname/src/Core
/projektname/src/Core/initcomponent.h
/projektname/src/Core/views
/projektname/src/Core/manager
/projektname/src/Core/models
/projektname/src/Core/controller
/projektname/src/Core/resources
/projektname/src/component_1/
/projektname/src/component_1/initcomponent.h
/projektname/src/component_1/views
/projektname/src/component_1/manager
/projektname/src/component_1/models
/projektname/src/component_1/controller
/projektname/src/component_1/resources
/projektname/src/component_2/
/projektname/src/component_2/initcomponent.h
/projektname/src/component_2/views
/projektname/src/component_2/manager
/projektname/src/component_2/models
/projektname/src/component_2/controller
/projektname/src/component_2/resources

Unterhalb von /src sind die Sourcen zu finden. Um das Projekt in logische Einheiten zu unterteilen, gibt es darunter ein Verzeichnis pro Komponente. Die Unterteilung soll später dabei helfen, dass Entwickler-Teams in verschiedenen Bereichen arbeiten können ohne sich gegenseitig zu behindern. Zudem soll eine leichtere Wiederverwertbarkeit von Komponenten damit gefördert werden. Es empfiehlt sich deshalb, die einzelnen Komponenten auch durch Namensräume von einander zu trennen. Z.B:

ProjectName::ComponentOne::View

Für das Kernmodul, in dem die grundliegenden Kernfunktionen der Webapplikation abgelegt sind,  empfiehlt es sich einen Namensraum wie „ProjectName::Core“ zu verwenden, natürlich mit einem gleichnamigen Verzeichnis „/Core“.

Komponenten-init-Funktion

Ich rate auch zu der Konvention, für jede Komponente eine Funktion zur Initialisierung der Komponente bereit zu stellen, die in einer Datei „initcomponent.h“ abgelegt ist und den gleichen Namen trägt ( also: „initcomponent()“). Diese Funktion sollte im Haupt- Programm (wahrscheinlich in der main()-Funktion) aufgerufen werden. Diese Funktion sollte alle notwendigen Vorbereitungen treffen, die für die Arbeit der Komponente wichtig sind. Das könnte z.B. die Konfiguration des Routings sein, oder die Initialisierung einer Random-Funktion für bessere Zufallszahlen.


Creative Commons Lizenzvertrag

C++-Webframeworks in Übersicht: Tntnet

Standard

Bei meiner Suche nach geeigneten Webframeworks, bin ich auf verschiedene Projekte gestoßen, die ich hier in einer kleinen Serie kurz vorstellen möchte:

Tntnet ist quasi das Urgestein der C++Web-Fremeworks. Das Projekt besteht schon seit ca. 2004. Ich war überrascht, dass Tntnet Bestandteil von Fedora-Linux ist. Ansprechend an Tntnet finde ich,  wie luftig und minimalistisch das Framework daher kommt. Alles ist so vertraut umgesetzt, wie ich es aus der C++-Welt gewohnt bin. Es gibt keine Vorgaben, wo Dateien liegen müssen, um von Tools gefunden werden zu können. Stattdessen wird eine Datei in einer speziellen Auszeichnungssprache erstellt. Sie besteht aus HTML und C++-Code und kann ggf. C++-Libs includieren. Diese Datei wird mit einem Precompiler zu einer „normalen“ C++-Datei umgewandelt. Aus der C++-Datei wird dann eine Objekt-Datei kompiliert. Eine Webapplikation besteht in der Regel aus mehreren Seiten, die ebenfalls als Objekt-Dateien übersetzt werden. Zum Schluss wird mit dem Linker aus den ganzen Objekt-Dateien eine Shared-Objekt-Lib erstellt. SO-Lib wird beim Starten des Applikation-Server geladen. Das Verhalten dabei kann recht genau über eine Konfigurationsdatei gesteuert werden. Wer – aus welchen Gründen auch immer – die Trennung zwischen Anwendung und Applikation-Server nicht wünscht, für den gibt es die Möglichkeit eine standalone web application zu erstellen. So erhält man, wie bei Wt, eine ausführbare Datei, in der alles enthalten ist.

ohloh_net_tntnet

Das Tntnet-Projekt unterstützt in erster Linie Linux/Unix. Für Windows gibt es derzeit wohl keine Nachfrage. Die Portabilität ist also eingeschränkt.

Siehe auch: „C++-Webframeworks in Übersicht: Als Tabelle“


Creative Commons Lizenzvertrag

C++-Webframeworks in Übersicht: Als Tabelle

Standard

Bei meiner Suche nach geeigneten Webframeworks bin ich auf verschiedene Projekte gestoßen, die ich hier in einer kleinen Serie kurz vorstellen möchte. Hier eine tabellarische Übersicht, über die vier wichtigsten Projekte:

Projektname Wt (Witty) CppCMS Tntnet Treefrog
Projektstart 2009 2008 2005 2011
Abstraktionslevel Sehr hoch Mittel Mittel Sehr hoch
Aktive Entwickler >5 1 >1 >2
Code-Zeilen 285.620 1.839.480 260.388 51.335
Prepompiler Nein Ja Ja Ja
Abhängigkeiten
  • CMake
  • Boost-Lib
  • OpenSSL  (Opt.)
  • Pango (Opt.)
  • Boost-Lib
  • Python 2.x
  • CgiCC
  • libgcrypt
  • gettext
  • cxxtools
  • automake*
  • autoconf*
  • libtool*
  • postgresql-devel**
  • zlib-devel
  • openssl-devel
Qt
Lizenz
  • Open  Source
  • proprietär
  • Open Source
  • proprietär
OpenSource OpenSource
Datenbank-
unterstüzung
  • Firebird
  • SQLite
  • PostgreSQL
  • MySQL
  • SQLite
  • PostgreSQL
  • MySQL
  • SQLite
  • PostgreSQL
  • MySQL
  • Oracle
Über Qt:

  • MongoDB
  • SQLite
  • PostgreSQL
  • MySQL
Mailingliste Ja (sehr aktiv) Nein Ja Ja
Authentifikations-
methoden
  • Facebook
  • Google
  • E-mail-Token
  • SHA1
  • MD5
  • OAuth
  • Token
Extras E-mail-Versand
  • Serialisierung
    • XML
    • Json
    • CSV
  • Logging
  • Komplexes URL-Routing
  • REST
    • XML
    • Json
    • Binary
    • CSV
  • SOA
  • Validation
  • Mailer
  • Logging
  • Plugin
  • Image Manipulation
Pakete in
Distributionen
Ja Nein Ja Nein
Dokumentation Mittel,
viele Beispiele
Wenig Mittel,
viele Beispiele
Mittel
OS
  • Linux
  • Windows/Cygwin
  • MacOS
  • Android
  • Raspberry Pi
  • QNX
  • Solaris
  • Linux
  • Windows/Cygwin
  • MacOS
  • FreeBSD
  • Linux
  • UNIX-like OS
  • Linux
  • Windows
  • UNIX-like OS
  • MacOS

Erläuterungen
* Abhängigkeit wenn die Bibliothek selber übersetzt wird.
** Abhängigkeit optionaler Funktionen.


Creative Commons Lizenzvertrag

Tntnet auf der Titelseite vom Linux-Magazin 01/2014

Standard

Linux-Magazin 01/2014

Tntnet hat es tatsächlich auf die Titelseite des Linux-Magazin 01/2014 geschafft. Auf Seite 90 ist ein 4 1/2 Seiten langer Artikel darüber zu finden. Tommi Mäkitalo und ich haben uns vor der Ausgabe 11/2013 dazu inspirieren lassen. Dort wurde von einer Art Programmierwettbewerb zwischen Contao, Rails, Django und Magnolia berichtet. Tommi und ich dachten uns, mit der gestellten Aufgabe können wir gut zeigen, was mit Tntnet und C++ in der Webprogrammierung möglich ist. Ich hoffe unser Artikel macht Lust, sich näher mit Tntnet zu beschäftigen. Viel Spaß beim Lesen.