Open Source Forum mit MySQL - Anbindung

[Rolf Rost]

Hallo,

hab in Punkto DBI und PERL und Speicherverwaltung in der letzten Zeit mal wieder einiges dazugelernt, wass ich nun natürlich auch in meinem kleinen Open Source Projekt umgesetzt habe.

Und da es eine Open Source ist, hab ich mir auch Mühe gegeben, die gut zu beschreiben:

http://rolfrost.de/opensource.html

Und das Ding ist sogar aktiv ;-)
http://rolfrost.de/cgi-bin/openforum.cgi

Eine Bitte hab ich: Wer in dieser Source Fehler findet, ist bitte sogut und informiere mich direkt.

Gute Reise Open Source ;-)

Gruss, Rolf

[Christoph Schnauß]

hallo Rolf,

Und da es eine Open Source ist, hab ich mir auch Mühe gegeben, die gut zu beschreiben:
http://rolfrost.de/opensource.html

Das ist eine Art README, ganz nett, aber es ist keine "Beschreibung". Der Hintergrund stört übrigens das Lesevergnügen.

Und das Ding ist sogar aktiv ;-)
http://rolfrost.de/cgi-bin/openforum.cgi

Was hast du denn gegenüber der vor knapp zehn Tagen in http://forum.de.selfhtml.org/archiv/2004/11/t95524 vorgestellten Fassung verändert?

Eine Bitte hab ich: Wer in dieser Source Fehler findet, ist bitte sogut und informiere mich direkt.

Ganz so schnell gehts nicht mit der Fehlersuche. Es gäbe vorerst allenfalls ein paar konzeptionelle Fragen. Mir fehlt zum Beispiel in deinem Script http://rolfrost.de/openforum.txt ein "use CGI".

Grüße aus Berlin

Christoph S.

[Rolf Rost]

Hi Christoph,

Und da es eine Open Source ist, hab ich mir auch Mühe gegeben, die gut zu beschreiben:
http://rolfrost.de/opensource.html

Das ist eine Art README, ganz nett, aber es ist keine "Beschreibung". Der Hintergrund stört übrigens das Lesevergnügen.

Hehe, ein bischen mehr ist es schon als eine README ;-)

Aber wenn in die Beschreibung noch was reinmuss, sag, schreibs hier, bitte...

Den Hintergrund gibts nur um die Weihnachtszeit, i.Ü., mir gefällt er.

Und das Ding ist sogar aktiv ;-)
http://rolfrost.de/cgi-bin/openforum.cgi

Was hast du denn gegenüber der vor knapp zehn Tagen in http://forum.de.selfhtml.org/archiv/2004/11/t95524 vorgestellten Fassung verändert?

Einiges. Ich hab die Implementierung des Transaktionskonzepts, was MySQL anbietet, für das Script überarbeitet, d.h., dieses nunmehr nur noch für das Erstellen neuer Records realisiert. Vorher hatte ich das Global im gesamten Script, was einige Nachteile mit sich bringen könnte, wie ich nachgelesen habe. Entsprechende Hinweise habe ich im LINUX Magazin gefunden, ich guck morgen mal auf meine andere Kiste und poste den Link, er ist auf jeden Fall interessant... hier ist noch ein anderer Link dazu

http://www.informit.com/articles/article.asp?p=23412

Damit ergibt sich letztendlich auch eine sauberer Code und einige weitere hilfreiche Kommentare habe ich in den letzten Tagen eingebaut, nicht nur auf og. Link sondern auch in der Source selbst.

Was Performance betrifft, hab ich in der funktion browse() noch was verbessert und auch beschrieben was es bringt - siehe Punkt 2 unter <h2>Performance</h2>. Auf jeden Fall wirkt es wie ein Turbo-Nachbrenner was ich auf meiner Testmaschine (P 266, 256 MB) deutlich feststellen kann ;-)

Eine Bitte hab ich: Wer in dieser Source Fehler findet, ist bitte sogut und informiere mich direkt.

Ganz so schnell gehts nicht mit der Fehlersuche.

Ist doch klar, ich hab das ja auch so gemeint, dass, wenn jetzt irgendwelche _groben_ Schnitzer aus der source direct ins Auge schreien, ich gerne asap eine Info wünsche ;-)

Es gäbe vorerst allenfalls ein paar konzeptionelle Fragen. Mir fehlt zum Beispiel in deinem Script http://rolfrost.de/openforum.txt ein "use CGI".

Das CGI Modul bietet ungeheuerlich viele Methoden an, wovon in dem kleinen Forum lediglich das Parsen der Formulareingaben gebraucht würde. Dafür jedoch reicht eine eigene kleine readparse() Funktion - und somit hab ich auf das Einbinden des CGI.pm hier mal verzichtet.

Falls das CGI.pm verwendet werden soll:
use CGI 'param';

und dann statt dem Aufruf von readparse() => Aufruf von param();
und statt $in{'FormFieldName'} => param('FormFieldName');

Der globale hash %in ist dann nicht mehr notwendig, die Änderungen sind ansonsten in relativ kurzer Zeit eingebaut.

CGI.pm bringt einige Vereinfachungen, u.a. für das handlen von cookies oder FileUploads.

Viele Grüße, Rolf

[Struppi]

Das CGI Modul bietet ungeheuerlich viele Methoden an, wovon in dem kleinen Forum lediglich das Parsen der Formulareingaben gebraucht würde. Dafür jedoch reicht eine eigene kleine readparse() Funktion - und somit hab ich auf das Einbinden des CGI.pm hier mal verzichtet.

Das CGI Modul bietet ungeheuer viele Funktionen für die HTML Ausgabe an, davon kann jedes CGI  Programm profitieren.

CGI.pm bringt einige Vereinfachungen, u.a. für das handlen von cookies oder FileUploads.

und im erstellen von HTML Formularen, HTML Tabellen, Links, Bildern, Listen, Header usw....

Du kannst mit dem Modul ein komplettes Skript, ohne eine einzige Zeile HTML code in deinem Perl Code zu benutzen, schreiben.

Struppi.

[Klaus Mock]

Hallo,

Das CGI Modul bietet ungeheuer viele Funktionen für die HTML Ausgabe an, davon kann jedes CGI  Programm profitieren.

Wobei ich der Meinung bin, dass HTML-Ausgabe und CGI nicht wirklich etwas miteinander zu tun hat. Auch ich finde, dass es besser gewesen wäre wenn es zwei Module geben würde, eines für das CGI an sich und ein zweites, mit dme man die ganze HTML-Geschichte abwickeln kann.

Grüße
  Klaus

[Struppi]

Wobei ich der Meinung bin, dass HTML-Ausgabe und CGI nicht wirklich etwas miteinander zu tun hat. Auch ich finde, dass es besser gewesen wäre wenn es zwei Module geben würde, eines für das CGI an sich und ein zweites, mit dme man die ganze HTML-Geschichte abwickeln kann.

Ich finde ohne HTML Ausgabe hast du kein CGI Programm. Ich wüßte nicht wie ich eine Tabelle ohne HTML ausgeben sollte in einem CGI Programm. Ich weiß das viele dann das Schlagwort Templates verwenden, aber um das sinnvoll einzusetzen muss man sich mit einer Template (Programmier-)Sprache rumschlagen. In meinen Augen ist es sinnvoller das CGI Skript nur HTML auszugeben und CSS Dateien einzubinden und dort das komplette Design zu integrieren.

Das Problem ist, dass die meisten sich gar nicht bewußt sind was das Modul alles kann und nur auf die von Rolf genannten Funktionen beschränken.

Struppi.

[Christian Kruse]

你好 Struppi,

Wobei ich der Meinung bin, dass HTML-Ausgabe und CGI nicht wirklich etwas miteinander zu tun hat. Auch ich finde, dass es besser gewesen wäre wenn es zwei Module geben würde, eines für das CGI an sich und ein zweites, mit dme man die ganze HTML-Geschichte abwickeln kann.

Ich finde ohne HTML Ausgabe hast du kein CGI Programm.

Dann ist

print <<TXT;
Content-Type: text/plain; charset=ISO-8859-15

Dies ist ein kleiner Text...

TXT

kein CGI-Programm? Nein, ein CGI-Programm muss nicht zwingend HTML
ausgeben...

再见,
 CK

[Struppi]

Dann ist

print <<TXT;
Content-Type: text/plain; charset=ISO-8859-15

Das musste ja kommen.

Dies ist ein kleiner Text...

TXT

kein CGI-Programm? Nein, ein CGI-Programm muss nicht zwingend HTML
ausgeben...

Klar.

Wieviel CGI Porgramme hast du so am laufen, die text/plain ausgeben?

Struppi.

[Christian Kruse]

你好 Struppi,

kein CGI-Programm? Nein, ein CGI-Programm muss nicht zwingend HTML
ausgeben...

Klar.

Wieviel CGI Porgramme hast du so am laufen, die text/plain ausgeben?

Auf Anhieb fallen mir gerade 5 ein. Mit etwas nachdenken noch ein paar mehr.
Und dann fallen mir noch mal ziemlich viele ein, die Bilder oder
dergleichen erzeugen.

再见,
 CK

[Struppi]

Wieviel CGI Porgramme hast du so am laufen, die text/plain ausgeben?

Auf Anhieb fallen mir gerade 5 ein. Mit etwas nachdenken noch ein paar mehr.
Und dann fallen mir noch mal ziemlich viele ein, die Bilder oder
dergleichen erzeugen.

Also, CGI Programme die eine HTML Ausgabe erzeugen sind also, wie wir erfahren, eher die Ausnahme.
Na gut, dann nehme ich meine Behauptung zurück. Ich hab vermutlich nicht genug Erfahrung.

Aber falls ihr solche seltene CGI Programme schreibt, die eine HMTL Ausgabe erzeugen ist das CGI Modul extrem hilfreich damit der Quelltext nicht durch HTML Tags unübersichtlich wird.

Struppi.

[Christian Kruse]

你好 Struppi,

Wieviel CGI Porgramme hast du so am laufen, die text/plain ausgeben?

Auf Anhieb fallen mir gerade 5 ein. Mit etwas nachdenken noch ein paar
mehr. Und dann fallen mir noch mal ziemlich viele ein, die Bilder oder
dergleichen erzeugen.

Also, CGI Programme die eine HTML Ausgabe erzeugen sind also, wie wir
erfahren, eher die Ausnahme. Na gut, dann nehme ich meine Behauptung
zurück. Ich hab vermutlich nicht genug Erfahrung.

Jetzt spiel nicht den Beleidigten. Ich habe derartiges nicht gesagt, noch
den Eindruck vermitteln wollen. Hier ging es darum, dass man die
HTML-Funktionen des CGI-Moduls besser in ein zweites Modul gepackt haette.
Und ich habe dir nur gezeigt, warum. Dazu kommt noch, dass man auch mit
Shell-Scripts HTML-Ausgaben machen kann (etwa um statische HTML-Ausgaben
zu erzeugen). Du hast es doch nicht geschrieben, warum fuehlst du dich
angegriffen, wenn Klaus oder ich sagen, es sei eine schlechte Idee
gewesen, dass in das CGI-Modul zu packen?

再见,
 CK

[Struppi]

HTML-Funktionen des CGI-Moduls besser in ein zweites Modul gepackt haette.
Und ich habe dir nur gezeigt, warum. Dazu kommt noch, dass man auch mit
Shell-Scripts HTML-Ausgaben machen kann (etwa um statische HTML-Ausgaben
zu erzeugen). Du hast es doch nicht geschrieben, warum fuehlst du dich
angegriffen, wenn Klaus oder ich sagen, es sei eine schlechte Idee
gewesen, dass in das CGI-Modul zu packen?

Vermutlich hätte man das tun können. aber wie gesagt - die meisten - CGI Programme  brauchen den Input und erzeugen den Output insofern ist (bzw. war, der Autor sieht das ja mittlerweile ähnlich) es naheliegend alle Funktionen in ein Modul zu packen . Zumal es ja auch Wechselwirkungen gibt, ich finde das automatische ausfüllen von Formularfeldern sehr praktisch und das geht nur, wenn das Modul zugriff auf param() hat.

Da die Parameter Verarbeitung vermutlich nicht den Großteil des Skriptes ausmacht (der Großteil des Quellcodes geht sowieso auf Kosten der Doku), wäre nicht viel gespart das auszulagern und wenn man wirklich nur den Input braucht gibt es ja auch CGI::Lite

Struppi.

[Rolf Rost]

hi Struppi,

Ich finde ohne HTML Ausgabe hast du kein CGI Programm. Ich wüßte nicht wie ich eine Tabelle ohne HTML ausgeben sollte in einem CGI Programm. Ich weiß das viele dann das Schlagwort Templates verwenden, aber um das sinnvoll einzusetzen muss man sich mit einer Template (Programmier-)Sprache rumschlagen. In meinen Augen ist es sinnvoller das CGI Skript nur HTML auszugeben und CSS Dateien einzubinden und dort das komplette Design zu integrieren.

Da bin ich voll und ganz Deiner Meinung!!!

Sicher können CGIs auch andere Content-types ausgeben. Btw., mit CGI.pm ist es ja auch möglich andere, als /text/html/header/ zu erzeugen...

Auf jeden Fall bevorzuge auch ich in meinen CGIs den 'direkten print' von HTML - Code nach STDOUT gegenüber einer Verwendung von HTML - Templates, für deren Verwendung ich bisher noch keinen Grund hatte.

Das Problem ist, dass die meisten sich gar nicht bewußt sind was das Modul alles kann und nur auf die von Rolf genannten Funktionen beschränken.

Das kann sogar ich sehr gut nachvollziehen. CGI.pm bietet ungeheuerlich viele Methoden an, HTML - Code zu erzeugen. Zum Beispiel auch zum Generieren von HTML - Tabellen um die mit dynamischen Inhalten zu füllen.

Dafür CGI.pm zu verwenden, das ist ganz sicher Gewohnheitssache. Ich für meinen Teil nehme gerne das Modul, wenn Cookies und Uploads zu machen sind. Gerade im Themenbereich Upload nimmt mir das Modul ne Menge Arbeit ab, es erstellt mir einen Handler, es gibt mir den Content-Type...

Viele Grüße,

Rolf

[Siechfred]

Tag Struppi.

Das CGI Modul bietet ungeheuer viele Funktionen für die HTML Ausgabe an, davon kann jedes CGI  Programm profitieren.

Ja, da stimme ich dir zu, gebe aber zu bedenken, dass Perl-Scripte, die ihre HTML-Ausgabe unter Zuhilfenahme des Moduls HTML::Template erzeugen, wesentlich einfacher zu pflegen sind, aber das ist nur mein persönliches Empfinden und natürlich Geschmackssache.

[dsf 3.6]
Siechfred

[Raik]

Hallo, Rolf!

Und da es eine Open Source ist, hab ich mir auch Mühe gegeben, die gut zu beschreiben:
http://rolfrost.de/opensource.html

"Das Blocken von Mehrfachposts funktioniert so, dass in die Tabelle locktable ein Schlüssel, welcher im Formular erzeugt wurde zusammen mit dem Zeitstempel des POST eingetragen wird."

wir haben hier letztens gerade eine lösung diskutiert, wo dieser schlüssel einfach gelöscht wird. existiert er nicht in der tabelle, gibts die fehlermeldung, undzwar unabhängig von der verzögerung der mehrfachabsendung.
für ein weiteres posting muss dann sowieso das formular neu geladen werden, wobei ein neuer, wieder gültiger schlüssel angelegt wird.
damit würde sich auch das spätere löschen "verbrauchter" schlüssel aus der tabelle erübrigen.

was hälst du davon?

freundl. Grüsse aus Berlin, Raik

[MudGuard]

Hi,

wir haben hier letztens gerade eine lösung diskutiert, wo dieser schlüssel einfach gelöscht wird. existiert er nicht in der tabelle, gibts die fehlermeldung, undzwar unabhängig von der verzögerung der mehrfachabsendung.
für ein weiteres posting muss dann sowieso das formular neu geladen werden, wobei ein neuer, wieder gültiger schlüssel angelegt wird.
damit würde sich auch das spätere löschen "verbrauchter" schlüssel aus der tabelle erübrigen.

Das kann zu einer Anhäufung von gültigen Schlüsseln führen, welche nie verwendet werden.
Weil der User u.U. das Formular anfordert, aber nicht ausfüllt und zurückschickt.

cu,
Andreas

[Raik]

Hallo, Andreas!

[...]
Das kann zu einer Anhäufung von gültigen Schlüsseln führen, welche nie verwendet werden.
Weil der User u.U. das Formular anfordert, aber nicht ausfüllt und zurückschickt.

da hast du allerdings recht. dafür kann ja weiterhin rolfs lösung mit der funktion clock() dienen, wenn man zu dem schlüssel jeweils einen tmestamp speichert.

freundl. Grüsse aus Berlin, Raik

[Rolf Rost]

Moin,

da hast du allerdings recht. dafür kann ja weiterhin rolfs lösung mit der funktion clock() dienen, wenn man zu dem schlüssel jeweils einen tmestamp speichert.

Auf jeden Fall lässt sich das optimieren, indem es in dieser locktable (oder auch sessiontable) einen index auf den Zeitstempel gibt. Dieser index greift dann in der where Klausel derart, dass die Funktion clock() schnell fertig ist, der Aufruf von clock() bei jedem Scriptdurchlauf ist dann tatsächlich nicht weiter 'tragisch'.

Und so sieht das dann auch aus: KEY idx (ts) <= timestap

CREATE TABLE locktable (
    initid varchar(100) NOT NULL default '',
    ts bigint(20) NOT NULL default '0',
    PRIMARY KEY  (initid),
    KEY idx (ts)
  ) TYPE=BerkeleyDB;

locktable clean_lock

alles loeschen was aelter als current_time - 10

sub clock{
 my $time = time - 10;
 $dbh->do("DELETE FROM locktable WHERE ts < '$time' ");
 return;
}### end sub clock

Btw. noch was zu transaktionen mit MySQL:

http://www.linux-magazin.de/Artikel/ausgabe/2001/08/mysql/mysql.html

Viele Grüße, Rolf

[Struppi]

http://www.linux-magazin.de/Artikel/ausgabe/2001/08/mysql/mysql.html

Irgendwie verstehe ich nicht, warum du so einen Aufwand betreibst.

Du kannst die entsprechende myISAM Tablle locken und dann die nächste freie ID suchen ud eintragen, dann kann erst ein gleichzeitiger Prozß darauf zugreifen und wird eine andere ID erzeugen. Soweit ich das PRinzip bisher verstanden habe ist locktable überflüssig.

Und doppeleinträge lassen sich einfach vermeiden, in dem man überprüft ob die Eingabe in dem thread mit der letzten Eingabe übereinstimmt.

Struppi.

[Rolf Rost]

hi Struppi,

http://www.linux-magazin.de/Artikel/ausgabe/2001/08/mysql/mysql.html

Irgendwie verstehe ich nicht, warum du so einen Aufwand betreibst.

Es sind 2 unabhängige Dinge die ich hier betrachte.
1. Transaktionskonzept
2. Mehfachpostingsperre

Du kannst die entsprechende myISAM Tablle locken und dann die nächste freie ID suchen ud eintragen, dann kann erst ein gleichzeitiger Prozß darauf zugreifen und wird eine andere ID erzeugen.

Das wäre ein Workaround zu 1. Und eine Alternative zum Transaktionskonzept. Aber wenn ich eine Engine hab, die Transaktionen unterstütz, komm ich drauf zurück. Es vereinfacht den Programmieraufwand.

Btw., so kritisch ist mit dem Transaktionskonzept nun auch wieder nicht, siehe Artikel weiter oben.

Soweit ich das PRinzip bisher verstanden habe ist locktable überflüssig.

... das ist dann der Workaround zu 2.

Und doppeleinträge lassen sich einfach vermeiden, in dem man überprüft ob die Eingabe in dem thread mit der letzten Eingabe übereinstimmt.

Genau das mache ich mit der locktable, in der art, dass jedem POST-Formular ein zufälliger string mitgegeben wird. Für eine Sperrzeit (unkritisch, ich nehme 2 sekunden weil in der zeit meistens die Umleitung erfolgte...) darf ein POST mit dieser initid nur einmal kommen.

Viele Grüße, Rolf

[Ludger]

Hi,

"Das Blocken von Mehrfachposts funktioniert so, dass in die Tabelle locktable ein Schlüssel, welcher im Formular erzeugt wurde zusammen mit dem Zeitstempel des POST eingetragen wird."

ich generiere einfach eine ID, die dem Formular beigefuegt wird, und in die Sessiontabelle geschrieben wird. Dann koennte man, sollte es eine Sessiontabelle geben, auf die Tabelle 'locktable' verzichten.

Gruss,
Ludger

[Rolf Rost]

Moin Raik,

[..]

damit würde sich auch das spätere löschen "verbrauchter" schlüssel aus der tabelle erübrigen.

was hälst du davon?

Die Idee ist gar nicht mal so schlecht. Allerdings kann es auch hier einen toten Record geben: wenn kein Post erfolgt, bleibt der key in der tab stehen. Also irgendeiner muss dann immer aufräumen ;-)

Viele Grüße, Rolf