suche einfaches CGI-Skript um Kommentare hinzuzufügen

[Marcel]

Ich habe jetzt schon den ganzen Nachmitag in irgend welchen archiven gesucht, aber nur kompliziertes und schwieriges zeugs gefunden.
Man soll in einem html-Formular in zwei eingabefeldern seinen namen und einen kommentar hineinschreiben. das ganze soll dann in der selben html-datei untereinander wiedergegeben werden, sofort nachdem man es eingegeben hat.
Kennt jemand eine fertige lösung, da ich mich nicht so gut auskenne?
ich wäre euch für eure hilfe sehr dankbar.
mfg Marcel

[Philipp Hasenfratz]

Halihallo Marcel

Ich habe jetzt schon den ganzen Nachmitag in irgend welchen archiven gesucht, aber nur kompliziertes und schwieriges zeugs gefunden.
Man soll in einem html-Formular in zwei eingabefeldern seinen namen und einen kommentar hineinschreiben. das ganze soll dann in der selben html-datei untereinander wiedergegeben werden, sofort nachdem man es eingegeben hat.
Kennt jemand eine fertige lösung, da ich mich nicht so gut auskenne?

</archiv/2002/9/22269/>, sollte einige Hints wie du sie wünschst enthalten (anscheinend nicht im richtigen Archiv gesucht *g*).

Viele Grüsse

Philipp

[Marcel]

</archiv/2002/9/22269/>, sollte einige Hints wie du sie wünschst enthalten (anscheinend nicht im richtigen Archiv gesucht *g*).

Hallo Philipp,
danke erstmal für deinen Tip.
Dein Vorschlag (siehe unten) gefällt mir schon ganz gut, aber wie gesagt ich kenne mich in perl gar nicht aus, kannst du villeicht das komplette skript notieren, dass ich es nur noch kopieren muss? sonst bekomme ich das nie hin. Wohin Kommen die Formularfelder, in die der name un der kommentar eingetragen werden? in die html datei?
danke im voraus
mfg marcel

in der HTML-Datei:

<a href="/cgi-bin/add_comment.pl?page=bilder1.html">Schreib ein Kommentar</a>
<!--Comments-here-->

in der Perl-Datei (Schritt 2/2):

open( F, $ENV{DOCUMENT_ROOT}.'/'.$cgi->param('page') );
while (<F>) {
   my $content .= $_;
}
close F;

$content =~ s/<!--Comments-here-->/$cgi->param(comment)/mig;

open( F, '>'.$ENV{DOCUMENT_ROOT}.'/'.$cgi->param('page') );
print F $content;
close F;

Schritt 1/2: Ausgabe des Commentar-Form's...

Nur mal so'n Beispiel. Mit $ENV{DOCUMENT_ROOT} bekommst du den absoluten Path zum Web. Durch den Parameter page kannst du die HTML-Seite, wo der Kommentar eingefügt werden soll angeben. Durch <!--Comments-here--> oder so kannst du dem Script sagen, wo die Kommentare hinsollen.

[Philipp Hasenfratz]

Halihallo Marcel

Dein Vorschlag (siehe unten) gefällt mir schon ganz gut, aber wie gesagt ich kenne mich in perl gar nicht aus, kannst du villeicht das komplette skript notieren, dass ich es nur noch kopieren muss?

Das gibt's hier nicht, ich habe dir genaugenommen schon zu viel geholfen, da ich dir ein fertiges Script zuzusagen vorgelegt habe ;-)
Aber helfen (sprich Anregungen geben) kann ich dir...

sonst bekomme ich das nie hin.

das glaube ich nicht! ;)

Wohin Kommen die Formularfelder, in die der name un der kommentar eingetragen werden? in die html datei?

Richtig. Du hast eine HTML-Datei mit einem Formular und einem HTML-Kommentar (dieser wird vom Perl-Script benötigt, um die Stelle zu kennzeichnen, wo es den User-Kommentar ablegen soll).

auszug aus comments.html

<form action="script...">
   <input type="text" name="comment" />
   <input type="hidden" name="comments.html" />
   <input type="submit" />
</form>

<h1> User-Kommentare </h1>
<!--Comments-here-->

Wenn also jemand einen Kommentar eingibt und dann auf submit klickt, wird das Perl-Script ausgeführt. Dieses öffnet nun die HTML-Seite (welche im versteckten Eingabefeld übergeben wird [welches immer den Dateinamen der HTML-Seite enthalten soll, in dem es sich befindet]) und fügt den Kommentar dort ein, wo sich "<!--Comments-here-->" gefindet. In der .zip Datei, welche im Thread genannt ist, ist ein fertiges Beispiel, das funktionieren dürfte.

Kommst du mit diesen Tipps weiter?

Viele Grüsse

Philipp

PS: Ich möchte an dieser Stelle darauf hinweisen, dass dieses Script nicht sehr "schön" ist. Es ist eigentlich nicht gut, wenn man HTML-Dateien auf dem Server ändert. Hierdurch entstehen sehr schnell Probleme (z. B. wenn man die lokale Datei nochmals auf den Server lädt => alle Kommentare weg, die durch das Script eingebunden wurden). Es wäre besser, wenn das Design (sprich die HTML-Datei) und die Daten getrennt wären.

[Marcel]

Servus Phillip,
nochmals danke für deine Hilfe, es klappt jetzt vorzüglich. Genau so wie ich es mir vorgestellt habe. Ich habe es bereits in eine Fotogalerie integriert. mfg Marcel

[Michael Schröpl]

Hi Philipp,

Wohin Kommen die Formularfelder, in die der name un der kommentar eingetragen werden? in die html datei?
Richtig.

wirklich? Was sollen sie da?

Semantisch betrachtet gehört das Formular zum Skript, nicht zum Dokument.

Und auch die eingefügten Kommentare gehören nicht wirklich zum Dokument, sondern in einen separaten Datenbereich. Stell Dir vor, Du willst ein neues Release aller Dokumente installieren ... möchtest Du dafür dann alle bereits installierten Dokumente editieren müssen? (Und während dieser Phase die Hinzufüge-Funktion abschalten, damit nicht beides miteinander kollidiert?)

Das angezeigte Dokument enthält Teile aus drei verschiedenen Quellen:

• seinen statischen Inhaltsanteil (erstellt vom Anbieter)
• seinen dynamischen Inhaltsanteil (inkrementell erstellt von vielen Besuchern) und
• seinen infrastrukturellen Inhaltsanteil (erstellt vom Anzeige- und Verarbeitungs-Skript - "Viewer" und "Poster" können sehr wohl identisch sein, bei der Self-Suchmaschine ist es beispielsweise genau so).

Da dieses Skript ohnehin notwendig ist, würde ich versuchen, die drei Informationseinheiten separat zu speichern, um sie so individuell wie möglich bearbeiten zu können (stell Dir vor, Du möchtest das Aussehen des Formulars ändern!), und das tatsächlich an den Anwender übertragene Dokument folglich bei jedem Aufruf dynamisch zusammenzubauen.

PS: Ich möchte an dieser Stelle darauf hinweisen, dass dieses Script nicht sehr "schön" ist.

Eben deshalb habe ich meine Anmerkungen dazu gepostet.

Es wäre besser, wenn das Design (sprich die HTML-Datei) und die Daten getrennt wären.

Full ACK. Die schwersten Fehler beim Entwurf einer Anwendung kann man im Datenmodell machen.

Viele Grüße
      Michael

[Philipp Hasenfratz]

Halihallo Michael

Wohin Kommen die Formularfelder, in die der name un der kommentar eingetragen werden? in die html datei?
Richtig.

wirklich? Was sollen sie da?

Die Funktionalität des Scriptes sicherstellen ;)

Semantisch betrachtet gehört das Formular zum Skript, nicht zum Dokument.

Die Bedeutung eines Formulars ist die Schnittstelle "Benutzer-Daten". Das Script "Daten-Verarbeitung". Diese "Prozesse" sind und sollten getrennt sein, wie also argumentierst du, dass das Formular semantisch zum Script gehören? - Dass die Daten zum Script gehören und nicht zu einer HTML Seite?

Und auch die eingefügten Kommentare gehören nicht wirklich zum Dokument, sondern in einen separaten Datenbereich. Stell Dir vor, Du willst ein neues Release aller Dokumente installieren ... möchtest Du dafür dann alle bereits installierten Dokumente editieren müssen? (Und während dieser Phase die Hinzufüge-Funktion abschalten, damit nicht beides miteinander kollidiert?)

Full ACK. Deshalb habe ich auch darauf hingewiesen. Dieses Script wurde von mir in einem "Eiltempo" für O. erstellt, sodass es gerademal der Aufgabenstellung gerecht wird. Es war Bestandteil der Aufgabenstellung, dass die Kommentare direkt in eine statische HTML Seite eingefügt werden und ohne SSI ist dies nicht anders realisierbar.

Da dieses Skript ohnehin notwendig ist, würde ich versuchen, die drei Informationseinheiten separat zu speichern, um sie so individuell wie möglich bearbeiten zu können (stell Dir vor, Du möchtest das Aussehen des Formulars ändern!), und das tatsächlich an den Anwender übertragene Dokument folglich bei jedem Aufruf dynamisch zusammenzubauen.

Letztere Aussage wäre wohl wünschenswert, jedoch war dies eben _nicht_ Bestandteil der Aufgabenstellung, ansonsten würde ich dir natürlich "entsprechen". Aber es gäbe in der Tat eine sehr sinnvollere Zwischenlösung, welche der Aufgabenstellung gerecht wird und die von dir genannten Nachteile dennoch vermindert: Das Script bewahrt die Daten separat auf, "kompiliert" jedoch die HTML-Seite bei jedem Post neu und speichert sie als .html im doc_root wieder ab. Somit kann der Anbieter die html seite editieren und als "Template" wieder auf dem Server abspeichern und riskiert keinen Datenverlust. Spätestens beim nächsten Post wird die Seite neu "berechnet".

---

Das Script wurde zu einer etwas speziellen Aufgabenstellung erstellt. Es ist klar, dass dieses bei anderen Aufg. falsch/schlecht umgesetzt ist. Dies habe ich zwar im ersten Posting angemerkt, aber danke für deine Ausführungen, welche die Problematiken damit klarer darstellen.

|T'Pol: I meant no insult.
|V'Lar: Of course not. You're simply speaking your mind ... as you always have.

paschta!
Fallen Hero... Irgendwie kam mir dieser Dialog doch bekannt vor ;)

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Philipp,

Wohin Kommen die Formularfelder, in die der name un der kommentar eingetragen werden? in die html datei?
Richtig.
wirklich? Was sollen sie da?
Die Funktionalität des Scriptes sicherstellen ;)

Eben. Wieso sollte die Funktionalität des Skripts von einem in jedem Dokument _vielleicht_ vorhandenen Formular abhängig gemacht werden, wenn es die Kontrolle über die Verfügbarkeit dieses Formulars auch selbst übernehmen könnte?
Das Formular in jedem Dokument zu speichern bedeutet Redundanz im Datenmodell und damit potentiell ein Integritätsproblem der Daten, welches die Funktionsfähigkeit des Skripts gefährden könnte.

Semantisch betrachtet gehört das Formular zum Skript, nicht zum Dokument.
Die Bedeutung eines Formulars ist die Schnittstelle "Benutzer-Daten". Das Script "Daten-Verarbeitung". Diese "Prozesse" sind und sollten getrennt sein, wie also argumentierst du, dass das Formular semantisch zum Script gehören? - Dass die Daten zum Script gehören und nicht zu einer HTML Seite?

Die vom Anwender eingegebenen Daten sind der dritte Teil des Datenmodells.
Der HTML-Code zur Darstellung eines Formulars zur Erfassung dieser benutzerspezifischen Daten ist inhaltlich betrachtet weder Teil der Originaldaten noch der benutzerspezifischen Daten - er ist das GUI des Skripts. Also gehört er zum Skript (als eine seiner Konfigurationsdateien).
Sowohl die Original-Daten als auch die benutzerspezifischen Daten sind ohne das Formular eigenständig auswertbar - beispielsweise durch einen Suchmaschinenindexer, dem ich nicht zumuten möchte, zu begreifen, daß er das Suchformular nicht verarbeiten soll, den Rest aber schon.

Letztere Aussage wäre wohl wünschenswert, jedoch war dies eben _nicht_ Bestandteil der Aufgabenstellung, ansonsten würde ich dir natürlich "entsprechen". Aber es gäbe in der Tat eine sehr sinnvollere Zwischenlösung, welche der Aufgabenstellung gerecht wird und die von dir genannten Nachteile dennoch vermindert: Das Script bewahrt die Daten separat auf, "kompiliert" jedoch die HTML-Seite bei jedem Post neu und speichert sie als .html im doc_root wieder ab. Somit kann der Anbieter die html seite editieren und als "Template" wieder auf dem Server abspeichern und riskiert keinen Datenverlust. Spätestens beim nächsten Post wird die Seite neu "berechnet".

Yep - das wäre die saubere Methode: Erst mal ein redundanzfreies Datenmodell entwickeln und später über Tuning-Maßnahmen nachdenken.
Redundanz mit bestimmten Zielsetzungen ist ja okay - Redundanz aus Nachlässigkeit, weil die Semantik der Daten nicht sorgfältig genug analysiert wurde, ist zu verurteilen.

Viele Grüße
      Michael