W
wodim
GESPERRT
Hallo,
Meine "Baustelle": Meine Homepage
Mein Ziel: Eine Webseite mit interaktiven Kontaktmöglichkeiten (letztlich "nur" als Mittel zum Zweck für mein Projekt), wie immer die das zu organisieren ist. Etwa in dem "Stil" wie die Startseite, mit folgenden Funktionalitäten:
Jeder (incl. Gäste) soll alles lesen können. Jeder registrierte und freigeschaltete User schreiben, wo es hinpasst (vorausgesetzt, er ist angemeldet), Themen erstellen können und seine eigenen Dinger ändern und löschen können. Ich als Admin will Lese- und Schreibzugriff auf alles. Und wenn sich meinetwegen wieder mal so'n "flodim" ...zigmal mit "Wegwerf" - Mailadressen unter wasweißichwievielen "Künstlernamen" wie "der_wahre_wodim" registriert, will ich ihn mit einem SQL - Statement 'rauskacheln können, aber ohne dass ich dazu phpMyAdmin brauche. Mailbenachrichtigung nicht zu vergessen. Also wenn's hoch kommt, schätzungsweise 10% von dem, was da jetzt in 80 MB Dateien und 69 Datenbanktabellen "organisiert" ist.
Mein ursprünglich angedachter Weg ("Verschmelzung" der Homepage mit dem phpBB - Forum) hat sich also sehr schnell als Sackgasse herausgestellt. Der Weg "ASP mit VB.NET" unter Windows auch, zumindest als Engstelle (Ressourcenfresser auf dem Windows - Server).
Das Ganze soll auf einem Linux - Server laufen. Aber als ein objektorientiertes Programm, nicht als plattformunabhängige Scripte, wie's üblicherweise gehandhabt wird (also bei meinem Hoster auch). Dass der Datenbankserver bei denen laufend überlastet war / abgeschmiert ist, lag z.B. an "schlampigen " Scripten bestimmter Kunden. Und wenn man wie ich als durch VB - und sonstige Programmierung "Verwöhnter" in PHP erst mal 'reinguckt wie das berühmte Schwein in's Uhrwerk, keimt sogar ein gewisses Verständnis für solche Nachlässigkeiten auf. Wenn einem dann allerdings ein "PC-Kiddie" vorexerziert, wie schön man mit so einem HTML / PHP - Mischmasch "Hackern" Tür und Tor öffnen kann, wenn man nicht aufpasst wie ein Heftelmacher (Stichwort: "SQL - Injections") - und um das wiederum abzufangen, noch mehrere "Schichten" angebracht wären... da hört der Spaß langsam auf. Geht mir weg mit Scripten!
Das Programm muss die User und Sessions verwalten, HTML Vorlagen (mit CSS - Stylesheets drunter) mit Werten aus der Datenbank "füllen" und den Usern übers Netz schieben. Und deren Eingaben verarbeiten. Für die Umgebung auf dem Server bin ich mit meinem Programm dann der einzige User.
Das Prinzip ist in allen objektorientierten Sprachen dasselbe. So wird's wohl üblicherweise praktiziert, wo User einer relationalen Datenbank vor ihrer grafischen Oberfläche (GUI) sitzen. Z.B. in meiner letzten Firma, wo ich für die an sowas mitprogrammiert habe. Die sog. "Three-Tier"- Architektur - drei Schichten:
(1.) "Ganz oben" das GUI, (3.) "ganz unten" die Datenbank. Dazwischen (2.) die "Objektschicht".
Beispiel: User Anton will die Daten von Kundin Berta sehen. Dazu tippt er Bertas Kundennummer ein. Das Programm guckt nun: Gibt's schon eine Instanz der Klasse "Kunde", bei der die Eigenschaft "Kundennummer" den Wert "Bertas Nummer" hat?
Ja? Dann nix wie her mit den Werten für die anderen Eigenschaften - und die gehen an das GUI von User Anton. Fertig. Da brauchen wir die Datenbank gar nicht.
Nein? Dann müssen wir ein Objekt der Klasse "Kunde" instanziieren und doch die Datenbank bemühen. Dafür basteln wir uns den SQL-String zusammen - und ab damit an die Datenbank. Die Daten kommen postwendend - rüber damit zum GUI von User Anton!
Fertig. Der einzige Unterschied: Hier ist das "Übertragungsmedium" zwischen den Schichten (1.) und (2.) halt nicht ein lokales Netz, sondern der Webserver und das Internet.
Ich brauche da also drei Datenbanktabellen: "User", "Posts", "Themen". Die treffendste Bezeichnung für mein Programm wäre also wohl: "Applikationsserver". Und am besten hat sich sowas für mich in VB gecodet. Ich hatte aber auch keine Probleme bei der Umstellung von Access Basic -> Visual Basic -> Centura -> Smalltalk. Nur meinetwegen jede Form von C (C++ / Visual C++ / C# /...) erscheint mir dagegen kryptisch:
Na, und so weiter - anderen geht's nun wieder genau umgekehrt, die können VB "nicht lesen"...
Also: Welche Sprache / Entwicklungs- und Testumgebung wäre für mich unter Linux etwa vergleichbar anzuwenden? (Unter Windows habe ich z.B. zum Testen XAMPP als Datenbank- und Webserver).
Meine "Baustelle": Meine Homepage
Mein Ziel: Eine Webseite mit interaktiven Kontaktmöglichkeiten (letztlich "nur" als Mittel zum Zweck für mein Projekt), wie immer die das zu organisieren ist. Etwa in dem "Stil" wie die Startseite, mit folgenden Funktionalitäten:
Jeder (incl. Gäste) soll alles lesen können. Jeder registrierte und freigeschaltete User schreiben, wo es hinpasst (vorausgesetzt, er ist angemeldet), Themen erstellen können und seine eigenen Dinger ändern und löschen können. Ich als Admin will Lese- und Schreibzugriff auf alles. Und wenn sich meinetwegen wieder mal so'n "flodim" ...zigmal mit "Wegwerf" - Mailadressen unter wasweißichwievielen "Künstlernamen" wie "der_wahre_wodim" registriert, will ich ihn mit einem SQL - Statement 'rauskacheln können, aber ohne dass ich dazu phpMyAdmin brauche. Mailbenachrichtigung nicht zu vergessen. Also wenn's hoch kommt, schätzungsweise 10% von dem, was da jetzt in 80 MB Dateien und 69 Datenbanktabellen "organisiert" ist.
Mein ursprünglich angedachter Weg ("Verschmelzung" der Homepage mit dem phpBB - Forum) hat sich also sehr schnell als Sackgasse herausgestellt. Der Weg "ASP mit VB.NET" unter Windows auch, zumindest als Engstelle (Ressourcenfresser auf dem Windows - Server).
Das Ganze soll auf einem Linux - Server laufen. Aber als ein objektorientiertes Programm, nicht als plattformunabhängige Scripte, wie's üblicherweise gehandhabt wird (also bei meinem Hoster auch). Dass der Datenbankserver bei denen laufend überlastet war / abgeschmiert ist, lag z.B. an "schlampigen " Scripten bestimmter Kunden. Und wenn man wie ich als durch VB - und sonstige Programmierung "Verwöhnter" in PHP erst mal 'reinguckt wie das berühmte Schwein in's Uhrwerk, keimt sogar ein gewisses Verständnis für solche Nachlässigkeiten auf. Wenn einem dann allerdings ein "PC-Kiddie" vorexerziert, wie schön man mit so einem HTML / PHP - Mischmasch "Hackern" Tür und Tor öffnen kann, wenn man nicht aufpasst wie ein Heftelmacher (Stichwort: "SQL - Injections") - und um das wiederum abzufangen, noch mehrere "Schichten" angebracht wären... da hört der Spaß langsam auf. Geht mir weg mit Scripten!
Das Programm muss die User und Sessions verwalten, HTML Vorlagen (mit CSS - Stylesheets drunter) mit Werten aus der Datenbank "füllen" und den Usern übers Netz schieben. Und deren Eingaben verarbeiten. Für die Umgebung auf dem Server bin ich mit meinem Programm dann der einzige User.
Das Prinzip ist in allen objektorientierten Sprachen dasselbe. So wird's wohl üblicherweise praktiziert, wo User einer relationalen Datenbank vor ihrer grafischen Oberfläche (GUI) sitzen. Z.B. in meiner letzten Firma, wo ich für die an sowas mitprogrammiert habe. Die sog. "Three-Tier"- Architektur - drei Schichten:
(1.) "Ganz oben" das GUI, (3.) "ganz unten" die Datenbank. Dazwischen (2.) die "Objektschicht".
Beispiel: User Anton will die Daten von Kundin Berta sehen. Dazu tippt er Bertas Kundennummer ein. Das Programm guckt nun: Gibt's schon eine Instanz der Klasse "Kunde", bei der die Eigenschaft "Kundennummer" den Wert "Bertas Nummer" hat?
Ja? Dann nix wie her mit den Werten für die anderen Eigenschaften - und die gehen an das GUI von User Anton. Fertig. Da brauchen wir die Datenbank gar nicht.
Nein? Dann müssen wir ein Objekt der Klasse "Kunde" instanziieren und doch die Datenbank bemühen. Dafür basteln wir uns den SQL-String zusammen - und ab damit an die Datenbank. Die Daten kommen postwendend - rüber damit zum GUI von User Anton!
Fertig. Der einzige Unterschied: Hier ist das "Übertragungsmedium" zwischen den Schichten (1.) und (2.) halt nicht ein lokales Netz, sondern der Webserver und das Internet.
Ich brauche da also drei Datenbanktabellen: "User", "Posts", "Themen". Die treffendste Bezeichnung für mein Programm wäre also wohl: "Applikationsserver". Und am besten hat sich sowas für mich in VB gecodet. Ich hatte aber auch keine Probleme bei der Umstellung von Access Basic -> Visual Basic -> Centura -> Smalltalk. Nur meinetwegen jede Form von C (C++ / Visual C++ / C# /...) erscheint mir dagegen kryptisch:
Na, und so weiter - anderen geht's nun wieder genau umgekehrt, die können VB "nicht lesen"...
Also: Welche Sprache / Entwicklungs- und Testumgebung wäre für mich unter Linux etwa vergleichbar anzuwenden? (Unter Windows habe ich z.B. zum Testen XAMPP als Datenbank- und Webserver).
(Das tun übrigens alle 3 Vorschläge von mir)
Was ist das?
