$1 mit $schritte++; oder so

[Ben]

Hallo

Wenn im Z.B in $laufe = "#Hund #Maus #Katze"; Steht

$tiere ="$laufe";
$tiere  =~ s/^ //i;
$tiere  =~s/# /#/gi;
$tiere =~s/ /-/gi;
$tiere  =~s/-#/#/gi;

$tiere  =~s/#([\w$SelectZ]+)/img src=$i.jpg/gi;

Dann erscheint in $tiere  Hund.jpg Haus.jpg Katze.jpg

Num sollen aber die Laufenden Schritte hinzu ermittelt werden, und hinter den Tieren stehen Hund.jpg(1) Haus.jpg(2) Katze.jpg(3)

Vielen Dank für eventuelle Hilfe

Ben

[Erwin]

Hi,

Num sollen aber die Laufenden Schritte hinzu ermittelt werden, und hinter den Tieren stehen Hund.jpg(1) Haus.jpg(2) Katze.jpg(3)

mal als einfache Lösung:

---------------8<---------------------

  
#!/usr/bin/perl  
  
use strict;  
use warnings;  
  
my $laufe = "#Hund #Maus #Katze";  
  
$laufe =~ s/#//g;  
my @erg = split / /,$laufe;  
  
my $num=1;  
foreach my $tier (@erg) {  
  print "$tier ($num)\n";  
  $num++;  
}  

--------------->8---------------------

Grüße,
 Erwin

[Ben]

Hallo

Vielen Dank es funktioniert!

Nun habe ich ein 2. Problem

input type=checkbox name=tier value=Hund
input type=checkbox name=tier value=Katze

Wen beim Absenden beide Checkboxen ausgewählt werden, wird nur
Hund oder Kaze im $in{'tier'} übertragen.

Ist es möglich dass allle ausgewählten Tiere im $in{'tier'} übertragen werden?

Vielen Dank

Ben

[Beat]

input type=checkbox name=tier value=Hund
input type=checkbox name=tier value=Katze

Wen beim Absenden beide Checkboxen ausgewählt werden, wird nur
Hund oder Kaze im $in{'tier'} übertragen.

Ist es möglich dass allle ausgewählten Tiere im $in{'tier'} übertragen werden?

Morgen

Die mehrfache Übertragung des gleichen Feldnamens mit verschiedenen (oder wiederholt gleichen) Werten ist Standard.
Wenn du das CGI Modul verwendest, wird dies von diesem Modul berücksichtigt.
Es ist allerdings möglich, dass du das Modul falsch anwendest, so dass du nur die erste Instanz des Arrays siehst und übernimmst.

Zeige deinen Code, wie du zu $in{'tier'} gelangst.

mfg Beat

[Ben]

Hi Beat,

Vielen Dank für deine Hilfe.

Habe einen anderen Abschnitt sub parse[ ersEtzt.
Nung geht es.
Lag wOhl irgendwo am parsen.

Vielen dank für deine Hilfe
Ben

[Ben]

Hi Beat,

Nun ist der Fehler Leider doch noch nicht Komplett behoben.

Und zwar geht es überall in Fehlermeldungen Dankeseiten.
Aber in der Email wird nur ein Wert Angezeigt obwohl alle ausgefüllt sind.

Hier der Code:

print MAIL"$in{'tiere'}";

<form action= "" method=post>
<input type="checkbox" name="tiere" value="Hund">Hund<BR>
<input type="checkbox" name="tiere" value="Katze">Katze<BR>
<input type="checkbox" name="tiere" value="Maus">Maus<BR>
<input type="submit"></form>

Vieleicht kennst Du eine Lösung?
Ben

[Beat]

Nun ist der Fehler Leider doch noch nicht Komplett behoben.
Und zwar geht es überall in Fehlermeldungen Dankeseiten.
Aber in der Email wird nur ein Wert Angezeigt obwohl alle ausgefüllt sind.

Hier der Code:

print MAIL"$in{'tiere'}";

Warum eine Variable in Anführungszeichen setzen?

Very Bad
   print "$somevar"

lazy style, Anfällig für Fehler
   print "somevar hat den Wert $somevar."

Sauber und klar (vor allem im Editor)
   print "somevar hat den Wert ", $somevar, " ."

<form action= "" method=post>

Umgang mit Anführungszeichen in Perl

schlecht
print "<elem par="val">";

gut, webkonform
print '<elem par="val">';

auch legal
print "<elem par='val'>";

oder alternativ
print q(<elem par="val" par='val'>);

oder
print qq(<elem par="val" par='val'>);

<input type="checkbox" name="tiere" value="Hund">Hund<BR>
<input type="checkbox" name="tiere" value="Katze">Katze<BR>
<input type="checkbox" name="tiere" value="Maus">Maus<BR>

Wo sind die label Elemente. gerade bei Checkboxen sind diese wichtig.

<input type="submit"></form>
Vieleicht kennst Du eine Lösung?

Sobald du mir die Fehler verursachende Stelle zeigst.
Derzeit zeigst du mir nur schlechten Stil.

$in{'tiere'} ist ein Hashelement das entweder einen Scalar enthält oder aber eine Referenz zu a) einem Scalar b) einem Array oder c) einem Hash.

Demonstriere, wie du zu $in{'tiere'} kommst.

Perl versteht übrigens auch $in{tiere} ohne Anführungszeichen.

mfg Beat

[Ben]

Hi Beat,

Hier der PArse Abschnitt.

sub ReadParse { local (*in) = @_ if @_;
local ($i, $key, $val); if ( $ENV{'REQUEST_METHOD'} eq "GET" )
{$in = $ENV{'QUERY_STRING'};}
elsif ($ENV{'REQUEST_METHOD'} eq "POST")
{read(STDIN,$in,$ENV{'CONTENT_LENGTH'});}
else {
$in = ( grep( !/^-/, @ARGV )) [0];
$in =~ s/\&/&/g; } @in = split(/&/,$in);
foreach $i (0 .. $#in) {
$in[$i] =~ s/+/ /g;
($key, $val) = split(/=/,$in[$i],2);
$key =~ s/%(..)/pack("c",hex($1))/ge;
$val =~ s/%(..)/pack("c",hex($1))/ge;
$in{$key} .= "\0" if (defined($in{$key}));
$in{$key} .= $val; } return length($in); }

&ReadParse;

Vieleicht liegt dort der Fehler, warum es überall geht nur nicht in der Email?

Ben

[Struppi]

Hier der PArse Abschnitt.

sub ReadParse { local (*in) = @_ if @_;

Das ist Code aus den 80'ern, willst du nicht umsteigen?
üblich ist das von Beat erwähnte CGI Modul.

Struppi.

[Ben]

Hi Struppi
Wo bekomme ich den dieses cgi Modul?
Ben Ps Vielen Dank für Deine Antwort

[Struppi]

Wo bekomme ich den dieses cgi Modul?

Das ist, bzw. wollte, bei jeder Perl Installation dabei (wie viele andere Module auch).

use CGI;

Struppi.

[Ben]

Wo bekomme ich den dieses cgi Modul?

Das ist, bzw. wollte, bei jeder Perl Installation dabei (wie viele andere Module auch).

use CGI;

Hi Struppi

Habe  unter
#!/usr/bin/perl
use CGI;
$cgi = new CGI;

eingefügt, funzt aber immer noch nur ein Wert in der Email von Checkbox.

MFG Ben

[Struppi]

Habe  unter
#!/usr/bin/perl
use CGI;
$cgi = new CGI;

eingefügt, funzt aber immer noch nur ein Wert in der Email von Checkbox.

In dem Code steht nicht, wie du den Wert abfragst und ich nehme an, dass du die Doku konsultiert hast, um deinem Problem eventuell auf die Spur zu kommen?

Struppi.

[Ben]

Hi Struppi

Hier dass Komplette Skript:

#!/usr/bin/perl -w
use CGI;
sub ReadParse { local (*in) = @_ if @_;
local ($i, $key, $val); if ( $ENV{'REQUEST_METHOD'} eq "GET" )
{$in = $ENV{'QUERY_STRING'};}
elsif ($ENV{'REQUEST_METHOD'} eq "POST")
{read(STDIN,$in,$ENV{'CONTENT_LENGTH'});}
else {
$in = ( grep( !/^-/, @ARGV )) [0];
$in =~ s/\&/&/g; } @in = split(/&/,$in);
foreach $i (0 .. $#in) {
$in[$i] =~ s/+/ /g;
($key, $val) = split(/=/,$in[$i],2);
$key =~ s/%(..)/pack("c",hex($1))/ge;
$val =~ s/%(..)/pack("c",hex($1))/ge;
$in{$key} .= "\0" if (defined($in{$key}));
$in{$key} .= $val; } return length($in); }
&ReadParse;
$cgi = new CGI;

print "Content-Type: text/html\n\n";
if($in{'tiere'} ne ''){
$mailp = "/usr/lib/sendmail";
$emailauto = " [e-mail]";
$subjectauto = "Test";
open(MAIL,"|$mailp -t");
print MAIL "To: $emailauto\n";
print MAIL "From: $emailauto\n";
print MAIL "Subject: $subjectauto\n\n";
print MAIL "$in{'tiere'}";
               close (MAIL);
print "Vielen Dank für die $in{'tiere'}";
}
print "<form action= "" method=post>
<input type="checkbox" name="tiere" value="Hund">Hund<BR>
<input type="checkbox" name="tiere" value="Katze">Katze<BR>
<input type="checkbox" name="tiere" value="Maus">Maus<BR>
<input type=submit></form>";

Ben

[Struppi]

Hier dass Komplette Skript:

Hier mal die komplette Doku.

#!/usr/bin/perl -w
use CGI;

üblich ist heutzutage noch:
use strict;

$cgi = new CGI;

Ich sehe nirgendwo, dass du das Modul auch benutzt zum einlesen der Parameter. Deine Funktion readParse kannst du dann übrigens wegschmeissen.

$emailauto = " [e-mail]";

Das wird nicht funktionieren uznd sollte dir als Warnungen auch in der Konsole ausgegeben werden, wenn du das Skript in der Konsole testest. In doppelten Anführungszeichen, werden Variabeln geparst, d.h. Perl such hier nach dem Array @aol

Struppi.

[Beat]

Hi Struppi

Hier dass Komplette Skript:

  
#!/usr/bin/perl -w  
  
# hier mach ich mal weiter.  
  
# dann fehlt was:  
  
use strict;  
  
# zwingt uns dazu alle Variablen mit my zu deklarieren. nämlich  
  
use CGI;  
# > $cgi = new CGI;  
my $cgi = new CGI;  
  
# Aufgabe aller CGI Programmierung: Jeder Userinput ist böse  
# wir müssen also den Userinput waschen und ihn dann zwischenspeichern.  
  
# Das CGI Modul nimmt uns Arbeit ab. Aber waschen müssen wir selber.  
# Wie waschen wir? Wir melden jeden Parameter an, den wir benutzen wollen  
  
# Ein hash von Listen  
# Das erste listenelement ist eine reguläre Expression.  
# Das zweite Element ist der Defaultwert, bei Tiere einfach '';  
my %DirtyInput = (  
   tiere => [ qr/^(?:kuh|pferd|schaf)$/, '' ],  
       # Ich will jedes Tier verwerfen,  
       # das nicht ein kuh ein schaf oder ein pferd ist  
   # hier weitere Parameter  
   # ...  
);  
  
my %CleanInput = ();  
# in diesem Hash sollen unsere gewaschenen Inputs gespeichert werden.  
  
# Nun will ich vom CGI Modul eine Liste aller Parameter,  
# um darüber iterieren zu können.  
  
foreach my $par ( $cgi->param ){  
   # in $_ ist der name des Parameter  
   # existiert dieser Name als Key in DirtyInputs ?  
   # sonst gehe einfach zum nächsten name  
   exists $DirtyInput{ $_ } or next;  
  
   # Der Wert jedes Parameters ist eine Liste, nicht ein einzelner Wert.  
   # Dies weise ich nun $CleanInput{$_} zu  
   # Der Ausdruck ist etwas kompliziert  
   $CleanInput{$_} = [];  #initialisiere mit leerer Liste  
   @{ $CleanInput{$_} } = grep/$DirtyInput{$_}[0]/, $cgi->param{$_};  
  
   # grep holt alle Elemente aus $cgi->param{$_}, welche  
   # die reguläre Expression,. die in $DirtyInput{$_}[0] gespeicert ist  
   # erfolgreich passieren.  
   # expandiert läuft also im Moment ab:  
   # @{ $CleanInput{tiere} } = grep/$DirtyInput{tiere}[0]/, $cgi->param{tiere};  
   # bzw...  
   # @{ $CleanInput{tiere} } = grep/^(?:kuh|pferd|schaf)$/, $cgi->param{tiere};  
  
}  
  

So, das macht er jetzt mit allen parametern.

Abfragen kannst du jetzt

  
  
foreach( @{ $CleanInput{tiere} } ) {  .... }  
  
print $CleanInput{tiere}[0];  
  
push @{ $CleanInput{tiere} }, "ziege";  
  
$CleanInput{haustiere} = $CleanInput{tiere};  
  

Weitere Kommentare

print "Content-Type: text/html\n\n";
if($in{'tiere'} ne ''){
$mailp = "/usr/lib/sendmail";

$emailauto = " [e-mail]";

my $emailauto

$subjectauto = "Test";

my ...

open(MAIL,"|$mailp -t");
print MAIL "To: $emailauto\n";
print MAIL "From: $emailauto\n";
print MAIL "Subject: $subjectauto\n\n";
print MAIL "$in{'tiere'}";

hier müsstest du jetzt schreiben

print MAIL @{ $CleanInput{'tiere'} }, "\n";

close (MAIL);
print "Vielen Dank für die $in{'tiere'}";
}
print "<form action= "" method=post>
<input type="checkbox" name="tiere" value="Hund">Hund<BR>

label Felder !

<input type="checkbox" name="tiere" value="Katze">Katze<BR>
<input type="checkbox" name="tiere" value="Maus">Maus<BR>
<input type=submit></form>";

mfg Beat

[Struppi]

Nun will ich vom CGI Modul eine Liste aller Parameter,

um darüber iterieren zu können.

foreach my $par ( $cgi->param ){

Naja, dadurch verbaust du ihm aber die Möglichkeit seinen Input einfach zu bearbeiten.

my @tiere = $cgi->param('tiere');  
....  
print MAIL "@tiere";  

Struppi.

[Beat]

Nun will ich vom CGI Modul eine Liste aller Parameter,

um darüber iterieren zu können.

foreach my $par ( $cgi->param ){

Naja, dadurch verbaust du ihm aber die Möglichkeit seinen Input einfach zu bearbeiten.

my @tiere = $cgi->param('tiere');

....
print MAIL "@tiere";

>   
> Struppi.  
  
Ich gebe zu, der Zugang zu komplexeren Datenstrukturen ist nicht gerade für den Anfänger.  
Auf der anderen Seite erachte ich es als Designfehler, Input aus der gleichen Quelle in verschiedenen unverbundenen Variablen abzuspeichern, weil du sie nie mehr zusammen anfassen kannst.  
Auch sind Hashkeys prädestiniert, um Feldnamen zu speichern. Einen Feldnamen als variable im Programm hart zu kodieren macht das Programm unflexibel.  
  
Nachtrag, da sind noch einige Typos im Script  
foreach my $par ( $cgi->param ){ ... }  
  
my $par ist unnötig, da ich ja sowieso $\_ verwende  
  
   $cgi->param{$\_}  
sollte  
   $cgi->param($\_)  
heissen, wie ja alle Methodenzugriffe von der Form  
   object->method()  
sind.  
  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o  
Der Valigator leibt diese Fische

[Struppi]

Ich gebe zu, der Zugang zu komplexeren Datenstrukturen ist nicht gerade für den Anfänger.
Auf der anderen Seite erachte ich es als Designfehler, Input aus der gleichen Quelle in verschiedenen unverbundenen Variablen abzuspeichern, weil du sie nie mehr zusammen anfassen kannst.

Wieso sollte man das wollen?
Der Input von CGI Programmen beinhaltet ja i.d.R. mehrere nicht zusammenhängende Para,eter, z.b. die Session, die Aktion, Zusätzliche Parameter für das entsprechende Modul, Debugparameter usw. usf. Die Inputs gehören meiner Meinung nur dahin, wo sie benötigt werden der Rest kümmert sich nicht darum.

Auch sind Hashkeys prädestiniert, um Feldnamen zu speichern. Einen Feldnamen als variable im Programm hart zu kodieren macht das Programm unflexibel.

Ich benutze den Input nur dort wo ich ihn brauche. Dort benenne ich dann die Variabel nach ihrem Verwendungszweck. Ich wüßte nicht was daran unflexibel ist.

Struppi.

[Beat]

Cookies sind eine andere Quelle als Post oder Get Daten. Sie haben ganz andere Lebensbedingungen.
Cookies sind ein Attribut des User-Agent. GET oder POST Daten sind Request Daten die mit einem Erzeuger-Dokument verbunden sind.

Auch sind Hashkeys prädestiniert, um Feldnamen zu speichern. Einen Feldnamen als variable im Programm hart zu kodieren macht das Programm unflexibel.
Ich benutze den Input nur dort wo ich ihn brauche. Dort benenne ich dann die Variabel nach ihrem Verwendungszweck. Ich wüßte nicht was daran unflexibel ist.

Ich habe nicht vor, die Waschmaschine mehr als notwendig zu bedienen.
Auch kann ich mit dem CGI Modul nicht komplexere Inputbäume parsen, weshalb ich es selbst nicht verwende.
Daraus ergibt sich automatisch, dass ich den bereinigten Input irgendwo speichere.

Ich will auch alle Festlegung über zulässigen Input an einem zentralen Ort, so dass er auch über Configfiles definiert werden kann.

You see...
Das ist zumindest in der Perl Welt so. In php kann das wieder anders aussehen.

mfg Beat

[Struppi]

Cookies sind eine andere Quelle als Post oder Get Daten. Sie haben ganz andere Lebensbedingungen.
Cookies sind ein Attribut des User-Agent. GET oder POST Daten sind Request Daten die mit einem Erzeuger-Dokument verbunden sind.

Wie kommst du jetzt auf Cookies?

Auch sind Hashkeys prädestiniert, um Feldnamen zu speichern. Einen Feldnamen als variable im Programm hart zu kodieren macht das Programm unflexibel.
Ich benutze den Input nur dort wo ich ihn brauche. Dort benenne ich dann die Variabel nach ihrem Verwendungszweck. Ich wüßte nicht was daran unflexibel ist.

Ich habe nicht vor, die Waschmaschine mehr als notwendig zu bedienen.

Waschmaschine???

Auch kann ich mit dem CGI Modul nicht komplexere Inputbäume parsen, weshalb ich es selbst nicht verwende.
Daraus ergibt sich automatisch, dass ich den bereinigten Input irgendwo speichere.

Was ich für unnötig erachte, da der Input dort bereinigt wird, wo ich ihn aufnehme und verwende, ich halte einen zentralen Input für überflüssig und in einer komplexeren Umgebung auch nicht für praktikabel.

Ich will auch alle Festlegung über zulässigen Input an einem zentralen Ort, so dass er auch über Configfiles definiert werden kann.

Das Bedürfnis hatte ich bisher nicht gehabt. Die zulässigen Inputs hängen doch in der Verantwortung der Module, die sie verarbeiten.

Das ist zumindest in der Perl Welt so. In php kann das wieder anders aussehen.

Ich glaube du kannst in PHP genau wie in Perl, die CGI Parameter zentral oder lokal aufnehmen. Ich weiß aber nicht, was du mit der Bemerkung meinst - ich kann kaum PHP.

Struppi.

[Beat]

Cookies sind eine andere Quelle als Post oder Get Daten. Sie haben ganz andere Lebensbedingungen.
Cookies sind ein Attribut des User-Agent. GET oder POST Daten sind Request Daten die mit einem Erzeuger-Dokument verbunden sind.

Wie kommst du jetzt auf Cookies?

Die Idee Cookies wurde durch dein Wort Sessions getriggert.
Dabei habe ich deine Aussage wohl überzogen.

Ich benutze den Input nur dort wo ich ihn brauche. Dort benenne ich dann die Variabel nach ihrem Verwendungszweck. Ich wüßte nicht was daran unflexibel ist.

Ich habe nicht vor, die Waschmaschine mehr als notwendig zu bedienen.

Waschmaschine???

Mein Script ist ein Context.
Der Context hat eine API. Es muss geklärt werden, was mit Input geschieht, der nicht verstanden wird.
Das hat noch nichts mit Ausgabekontext zu tun.

Der Begriff 'waschen' ist im Zusammenhang mit untainting Mechanismen, deren es eigentlich nur einen gibt in Perl, stehend.

Auch kann ich mit dem CGI Modul nicht komplexere Inputbäume parsen, weshalb ich es selbst nicht verwende.
Daraus ergibt sich automatisch, dass ich den bereinigten Input irgendwo speichere.

Was ich für unnötig erachte, da der Input dort bereinigt wird, wo ich ihn aufnehme und verwende

Nicht dort wo, sondern bevor... egal ob eine Zeile bevor, aber bevor.

Dieses "bevor" kann aber sehr blöd werden wenn es dezentral immer wieder geschehen muss.

$UnClean{integer_one_char}
Willst du das jedes mal überprüfen? Das ist nicht wartbar.
Wie wenn dir dann einfällt, dass dieses Feld nun zwei Integerzeichen lang sein darf?

Du erlaubst die Angabe einer Mailadresse.
Du hast die Wahl diese Angabe einmal zu validieren (soweit sinnvoll), oder unvalidiert zu speichern und dann das bei jeder Verwendung nachzuholen.
Das ist nicht praktikabel.

, ich halte einen zentralen Input für überflüssig und in einer komplexeren Umgebung auch nicht für praktikabel.

Ach ich schon. Die Komplexität meiner drei grösseren Anwendungen ist mir deshalb nicht über den Kopf gewachsen, weil ich den Context Script-Input zentral verwalte.

Ich will auch alle Festlegung über zulässigen Input an einem zentralen Ort, so dass er auch über Configfiles definiert werden kann.

Das Bedürfnis hatte ich bisher nicht gehabt. Die zulässigen Inputs hängen doch in der Verantwortung der Module, die sie verarbeiten.

Und wie teilst du den Modulen mit, was der Inhalt von Feld XY formal sein darf?
Du brauchst für jedes Modul eine zentrale Erkundigungsstelle.

Das ist zumindest in der Perl Welt so. In php kann das wieder anders aussehen.

Ich glaube du kannst in PHP genau wie in Perl, die CGI Parameter zentral oder lokal aufnehmen. Ich weiß aber nicht, was du mit der Bemerkung meinst - ich kann kaum PHP.

ebenfalls.

In PHP ist es eine Untugend, Variablen zu kopieren. Primär erzeugst du dabei Aliase, die erst bei einer Wertveränderung an diesem Alias zu echten Kopien werden.

mfg Beat

[Struppi]

Ich benutze den Input nur dort wo ich ihn brauche. Dort benenne ich dann die Variabel nach ihrem Verwendungszweck. Ich wüßte nicht was daran unflexibel ist.

Ich habe nicht vor, die Waschmaschine mehr als notwendig zu bedienen.

Waschmaschine???

Mein Script ist ein Context.
Der Context hat eine API. Es muss geklärt werden, was mit Input geschieht, der nicht verstanden wird.

Der wird irgnoriert.

Dieses "bevor" kann aber sehr blöd werden wenn es dezentral immer wieder geschehen muss.

$UnClean{integer_one_char}
Willst du das jedes mal überprüfen? Das ist nicht wartbar.
Wie wenn dir dann einfällt, dass dieses Feld nun zwei Integerzeichen lang sein darf?

Üblicherwiese fällt das in den Aufgabenbereich des Formulagenerators. Du erzeugst ein Formular mit Formularfeldern und wenn du dies zentral machst, legst du dort auch die Definition welche Werte erlaubt sind ab.

Du erlaubst die Angabe einer Mailadresse.
Du hast die Wahl diese Angabe einmal zu validieren (soweit sinnvoll), oder unvalidiert zu speichern und dann das bei jeder Verwendung nachzuholen.
Das ist nicht praktikabel.

Wieso nicht? Ich nehme diesen Wert auf und habe danach ein Model mit einem Datenfeld auf  das ich mit einem getter zugreife datenmodel->mail() und das verwende ich.

, ich halte einen zentralen Input für überflüssig und in einer komplexeren Umgebung auch nicht für praktikabel.

Ach ich schon. Die Komplexität meiner drei grösseren Anwendungen ist mir deshalb nicht über den Kopf gewachsen, weil ich den Context Script-Input zentral verwalte.

Nein, du schleppst diese Werte aber überall mit. Dabei brauchst du in einem Kontext nur die Werte die der Kontext bennötigt, alle anderen Werte sind uninteressant.

Ich will auch alle Festlegung über zulässigen Input an einem zentralen Ort, so dass er auch über Configfiles definiert werden kann.

Das Bedürfnis hatte ich bisher nicht gehabt. Die zulässigen Inputs hängen doch in der Verantwortung der Module, die sie verarbeiten.

Und wie teilst du den Modulen mit, was der Inhalt von Feld XY formal sein darf?
Du brauchst für jedes Modul eine zentrale Erkundigungsstelle.

Die Parameter die reinkommen können so strukturiert sein

Allgemein action/session/timestamp
Action:
Login   user/passwort
Forum   user/b_id/t_id/m_id/text/titel/
Message user/von/titel/text

Wer verarbeitet den Input:
action ==> dispatcher()
session => sessionModul()
timestamp => spammodul()
im Dispatcher wird erzeugt
user/passwort => usermodel()
b_id/t_id/m_id/titel/text ==> forummodul()
von/titel/text ==> nachrichtenmodul()

Natürlich muss dann, z.b. das Forummodul Wissen, dass die id's Zahlen sein müssen und titel Text. Ob aber HTML zugelassen ist oder nicht, wird in einer Konfiguration gespeichert. Jetzt kann es aber sein, dass in einem Nachrichtensystem ebenfalls der Parameter titel verwendet wird, dort sind aber andere Filterkritierien wichtig, z.b. wenn sie per Mail verschickt wird, darf das Subjekt kein Zeilenumbruch enthalten, in einer Forumsnachricht spielt das keine Rolle. Es wäre also nicht hilfreich das zentral zu machen, zumal viele Parameter nur für einzelne Module nötig sind und daher gar nicht bearbeitet werden müssen.

Struppi.

[Beat]

$UnClean{integer_one_char}
Willst du das jedes mal überprüfen? Das ist nicht wartbar.
Wie wenn dir dann einfällt, dass dieses Feld nun zwei Integerzeichen lang sein darf?

Üblicherwiese fällt das in den Aufgabenbereich des Formulagenerators. Du erzeugst ein Formular mit Formularfeldern und wenn du dies zentral machst, legst du dort auch die Definition welche Werte erlaubt sind ab.

Es gibt viele Formulare zu den gleichen Daten.
Ich fordere dass Validierung eher eine Eigenschaft des Datenmanagers ist.

mehr dazu folgt

Du erlaubst die Angabe einer Mailadresse.
Du hast die Wahl diese Angabe einmal zu validieren (soweit sinnvoll), oder unvalidiert zu speichern und dann das bei jeder Verwendung nachzuholen.
Das ist nicht praktikabel.

Wieso nicht? Ich nehme diesen Wert auf und habe danach ein Model mit einem Datenfeld auf  das ich mit einem getter zugreife datenmodel->mail() und das verwende ich.

OK, dann modularisierst du alle deine Feldtypen in ein eigenes Modul.
Das ist eine Frage ob einem das behagt.

Übrigens widersprichst du gerade oben. Ein Formularmanager ist ein Viewer der Daten. Nicht ein Model.

Ich denke weniger MVC-orientiert [1], sondern eher entlang zusammenfassender Datenbeschreibung. Das liegt vielleicht darin begründet, dass mir schwindlig wird, wenn ich mehr als drei Editor Tabs zum gleichen Framework offen habe.

[1] eventuell unterstelle ich etwas?

...

Und wie teilst du den Modulen mit, was der Inhalt von Feld XY formal sein darf?
Du brauchst für jedes Modul eine zentrale Erkundigungsstelle.

Die Parameter die reinkommen können so strukturiert sein

snipp...

Daten geparst

...snipp

Natürlich muss dann, z.b. das Forummodul Wissen, dass die id's Zahlen sein müssen und titel Text. Ob aber HTML zugelassen ist oder nicht, wird in einer Konfiguration gespeichert. Jetzt kann es aber sein, dass in einem Nachrichtensystem ebenfalls der Parameter titel verwendet wird, dort sind aber andere Filterkritierien wichtig, z.b. wenn sie per Mail verschickt wird, darf das Subjekt kein Zeilenumbruch enthalten, in einer Forumsnachricht spielt das keine Rolle. Es wäre also nicht hilfreich das zentral zu machen, zumal viele Parameter nur für einzelne Module nötig sind und daher gar nicht bearbeitet werden müssen.

Die Kontextspezifische Ausgabe ist natürlich auf eine sub oder ein Modul zu reduzieren, wobei dann dieser Ausgabefilter, wenn ich es recht verstehe, im Viewer eingebunden wird.

Für mich gibt es zwei Arten von Daten:
Userdaten und Programm-Eigenschaft-Daten.
Es ist auch für mich klar, dass ich diese verschieden organsisiere.
Eine modularisierung von Ausgabefiltern mache ich nur bei Programmen, bei welchen ich ein starkes Wachstum vermute. Das liegt wohl daran, dass bestimmte Filter so einfach sind, dass sie in einer sub gut unterkommen.

Zu deinem Datenbeispiel

Ich nenne das mal eine Vektor-Orientierte Datenstuktur. Alles zeigt auf etwas anderes als zusätzliche Quelle oder Festlegung.
Ich halte das durchaus für eine mögliche Struktur, die aber spezifische Arbeitsinstrumente bedarf, die den normalen Editor übersteigen. Du musst den gesamten Informationsfluss quer über Dateien zu einem Parameter surfen können um deine Baustelle zu erfassen.
Für mich aber gibt es Datentypen, und Userdaten gehören hierzu, die irgendwo einen abgeschlossenen Kontext bilden, und die frei von Ringförmigen Abhängigkeiten sein müssen. Ob ich sie als Tabelle speichere oder als hash baum, das ganze muss einen Anfasser haben, und ich muss die Daten letztlich auch frei machen können vom Werkzeug, in welchem diese Daten ja nur behandelt werden.
Aber auch für die Architekturdaten braucht es dann irgendwo eine Sicherheit, dass ein Baumartiges Konstrukt vorliegt. Wenn zirkulärschleifen entstehen, dann hat man oft schwer durchschaubare Vorgänge. Hier sehe ich eine potentielle Gefahr von solchen Vektor orientierten Strukturen. Vielleicht gerade im Zusammenhang mit der Dateizersplitterung.

Vielleicht nur um den Thread noch zu schliessen, die Frage:
Wie organisierst du diese Arbeit praktisch?

mfg Beat

[Struppi]

OK, dann modularisierst du alle deine Feldtypen in ein eigenes Modul.
Das ist eine Frage ob einem das behagt.

Übrigens widersprichst du gerade oben. Ein Formularmanager ist ein Viewer der Daten. Nicht ein Model.

Ja ich weiß, weil ich bisher noch keinen Formularmanager verwende. Da ich den Umbau auf ein vollständiges MVC Konzept noch nicht vollzogen habe (deshalb schrieb ich auch üblicherweise).

Was mich aber an einer zentralen Inputkontrolle/-filter stören würde, ist auch dass du nicht mehr an die fehlerhafte Eingaben kommst, um z.b. festzustellen ob hier ein bösartiger Angriff vorliegt.

Vielleicht nur um den Thread noch zu schliessen, die Frage:
Wie organisierst du diese Arbeit praktisch?

Ich weiß nicht, ob ich deine Ausführungen richtig verstanden habe. Ich sehe das ganze im Kontext einer Webanwendung, d.h. ich hab einen Request und einen Response. Dazwischen  sitzt der Dispatcher (oder Frontcontroller), der die verschiedenen Objekte zusammenführt.

Mir ist aber nicht ganz klar, was du unter Vektor Orientierte Struktur verstehst. Aber eine Dateizersplitterung ist, glaube ich, ein übliche Geschichte bei einer CGI Anwendung. Du musst ja bei jedem Aufruf nur einen winzigen Bruchteil der Aufgaben erfüllen, die deine Anwendung kann. Es wäre overkill bei jedem Aufruf immer alles auf's neue zu laden.

Oder meinst du mit organisieren, im Editor? Ich habe i.d.R. ca. 10 Dateien offen. Was tatsächlich hin und wieder schwierig wird. aber es geht nicht anders.

Struppi.

[Beat]

Was mich aber an einer zentralen Inputkontrolle/-filter stören würde, ist auch dass du nicht mehr an die fehlerhafte Eingaben kommst, um z.b. festzustellen ob hier ein bösartiger Angriff vorliegt.

OK, sehr formal gebe ich dir da recht.
Aber in dem Fall hast du einen speziellen Datentyp Rohdaten.
Ich zähle eher auf spezifisch gestaltete Felder die diesem Zweck dienen, als auf Felder, die ich nicht vorgesehen habe, die aber ein Browser aus was für Gründen auch sendet.

Ich tendiere übrigens dazu, Firewall Software oder zeitkritische Software von generellen Überlegungen hier auszunehmen. Ich sehe das wirklich als eine Diskussion über CGI typische Anwendungen.

Vielleicht nur um den Thread noch zu schliessen, die Frage:
Wie organisierst du diese Arbeit praktisch?

Ich weiß nicht, ob ich deine Ausführungen richtig verstanden habe. Ich sehe das ganze im Kontext einer Webanwendung, d.h. ich hab einen Request und einen Response. Dazwischen  sitzt der Dispatcher (oder Frontcontroller), der die verschiedenen Objekte zusammenführt.

Mir ist aber nicht ganz klar, was du unter Vektor Orientierte Struktur verstehst. Aber eine Dateizersplitterung ist, glaube ich, ein übliche Geschichte bei einer CGI Anwendung. Du musst ja bei jedem Aufruf nur einen winzigen Bruchteil der Aufgaben erfüllen, die deine Anwendung kann. Es wäre overkill bei jedem Aufruf immer alles auf's neue zu laden.

Das ist richtig.
Die Winzigkeit beruht aber immer häufiger darin: Sessionhandling, Userspezifische Konfigurierung, Reinholen der letzten aktuellen Daten, damit der Ablauf user-gerecht ist, etc...
Es gibt Userdaten, die du einfach immer brauchst.
Ich Teile meine Userdaten normalerweise in zwei Teile: immer präsente und nachzuladende.

In BdE-Online habe ich einen Loadmanager, der wirklich nur auf Bedarf (nach) lädt. Ich verwende auch einen Cache für rechenintensivere Sachen (Stichwort CPU leistung auf einen anderen ort verlagern).

Aber das Modulprinzip (Perlmodule) heisst ja auch, dass ich alles immer lade, wenn auch nur als Programmstruktur. (ein Grund warum ich für gut getestete Module oft require verwende, auch wenn ich sie mit use entwickle)

Ich habe für mein CMS ein Sprachpaket als Modul. Ich muss in der Tat das ganze Sprachpaket laden. Dieses aufzusplitten (zum beispiel in mehrer Files pro "Viewer") macht es nicht einfacher, weil ich dann nur die Baustellen vervielfache.
Es ist eben eine Krankheit von CGI, dass man einer spontan konfigurierbaren GUI gerecht werden muss.

Oder meinst du mit organisieren, im Editor?

Eigentlich ja

Ich habe i.d.R. ca. 10 Dateien offen. Was tatsächlich hin und wieder schwierig wird. aber es geht nicht anders.

Ah der sogenannte Fenster-Groove, den ich meine.
Irgendwo fehlt eben so eine Art DOM Viewer, also ein Tool, mit welchem man innerhalb eines Verzeichnisses den Fluss von Variablen nachzeichnen kann.
(was wiederum sehr sprachabhängig ist).

mfg Beat

[Pragma]

Context API, Vektor-Orientierte Datenstuktur, MVC, Fenster-Groove...

Interessanter als das Buzzword-Bingo finde ich die eigentliche Frage:

"Wo und wann findet die Validierung des Inputs statt?"

Antwort a) Beat: Direkt nach "CGI In" am Anfang des Scripts - pauschal für alles
Antwort b) Struppi: Innerhalb des jeweiligen Script-Kontext. Pseudo-Beispiel: sub XXX ($evtl_boese = shift; $evtl_boese =~ /^[1]*$/ || die 'böse')

IMHO kann (sprachunabhängig) nur b) Sinn machen. "sub XXX" will ich in meinem nächsten Projekt wiederverwenden, ohne mir erneut um die Validierung nen Kopp machen zu müssen...

Tatsächlich ist a) gefährlich, vergesse ich nämlich beim nächsten Projekt die "Zentral-Begin-Validierung" und schiebe "sub XXX" etwas böses unter, dann knallt es womöglich.

Also _muss_ "sub XXX" selbst die Integrität der Daten prüfen.

---

1. 0-9 ↩︎

[Beat]

Tatsächlich ist a) gefährlich, vergesse ich nämlich beim nächsten Projekt die "Zentral-Begin-Validierung" und schiebe "sub XXX" etwas böses unter, dann knallt es womöglich.

Man kann sich immer selbst besiegen, ebenso wie man ein HTML Dokument ohne Doctype schreiben kann.

Also _muss_ "sub XXX" selbst die Integrität der Daten prüfen.

Dann ist es kein sub, sondern ein autarkes selbstverantwortliches Ding mit seinem eigenen EVA Prinzip, das irgendwo im Netz betrieben wird.

Unter einer sub verstehe ich etwas, das im Namensraum eines Chefs sitzt.

Wenn ich das CGI Modul verwende, dann hole ich mir ziemlich viel in den Namensraum. wenn ich jede sub jungfräulich immer wieder neu auf $cgi->param zugreifen lasse, habe ich zwar pseudojungfräuliche Daten. Ich muss sie dann aber doch nach einem zentralen Schema validieren, bevor ich die Daten benutzen kann. Wenn eine sub findet "Ich erfinde jetzt andere Gesetze", dann hat das in diesem Namensraum nichts mehr zu suchen.

Aus diesem Grund ist es das masterscript allein, das hand an CGI Daten legen darf. Module werden nur über das Masterscript bedient, und Daten nur vom Masterscript wieder empfangen. Aber es ist unmöglich, dass ein Modul eigenständig den CGI Input parst und validiert und dann etwas unterschieben will.

Ich meine, dass ist eine Frage der policy, die man sich innerhalb einer Sprache aneignet.

Wenn du quer über Sprachen , Prozesse und Userrechte programmierst, dann hast du allerdings überall dein eigenes EVA prinzip zu erfolgen, wobei du dann dennoch eine gemeinsame Semantik, einen übersprachlichen Standard pflegen musst.

Tatsächlich dürfte Version b) geeignet sein für verzweigte Anwendungen quer durch verschieden Autoren Sprachen und Datei-Rechte. Aber ich halte es für sinnlos aufwändig und zerfleddert, wenn wir einen CGI Context unter einer Domäne und einer Sprache vor Augen haben.

Der nächste Punkt ist.
Validierung hat weniger damit zu tun, über möglichen Spamangriffen zu brüten. Es hat damit zu tun, dass Usereingaben in eine kanonische Form gebracht werden. Dieser Vorgang selbst kann für ein Feld komplexer werden, und verdient deshalb, zentral behandelt zu werden. Usereingaben stehen unter keinem Kulturgüterschutz. Sie wurden in Anlass einer Anwendung, einer API getätigt. Und eine API kann diese Eingaben normalisieren oder kanonisieren, bzw eine errormessage auf eine queue setzen.

War diessen vorgang in eng angebunden Bestandteile (subs oder module) mehr als einmal abdelegiert, befindet sich im Spaghetticode einer anderen Dimension.

mfg Beat

[Pragma]

ist es das masterscript allein, das hand an CGI Daten legen darf.

100% Zustimmung. "sub XXX" bekommt Paramter, die das aufrufende Main übergibt. Ob Main die ausm CGI, ausm TXT File oder ausm SDTIN holt, ist völlig egal. Die Prüfung ob der Integratität des Paramters gehört zur Aufgabe von "sub XXX".

Es geht nicht darum, dass "sub XXX" den CGI Input parsen soll, sondern um die Anforderung, das "sub XXX" gefälligst für die Valdierung seiner Eingangsparmeter zu sorgen hat.

Unter einer sub verstehe ich etwas, das im Namensraum eines Chefs sitzt.
War diessen vorgang in eng angebunden Bestandteile

Verstanden. Du beschränkst sub also auf einen spezifischen Code-Block innerhalb _einer_ Aufgabenstellung. OK. Sobald Du (wie Du Deine Namensräume hierbei organisierst, hat damit IMHO erstmal nichts zu tun) _eine_ "sub" nun aber aus verscheindenen "Mains" z.B. "main1.pl, main2.pl" verwenden willst, sieht die Sache spätestens anders aus... Das muss kein "autarkes selbstverantwortliches Ding mit seinem eigenen EVA Prinzip, das irgendwo im Netz betrieben wird" sein, sondern kann schlicht etwas darstellen, was ich innerhalb wiederkehrender Aufgabenstellungen verwenden möchte, um meinen Code sauber zu organisieren.

[Beat]

Verstanden. Du beschränkst sub also auf einen spezifischen Code-Block innerhalb _einer_ Aufgabenstellung. OK. Sobald Du (wie Du Deine Namensräume hierbei organisierst, hat damit IMHO erstmal nichts zu tun) _eine_ "sub" nun aber aus verscheindenen "Mains" z.B. "main1.pl, main2.pl" verwenden willst, sieht die Sache spätestens anders aus... Das muss kein "autarkes selbstverantwortliches Ding mit seinem eigenen EVA Prinzip, das irgendwo im Netz betrieben wird" sein, sondern kann schlicht etwas darstellen, was ich innerhalb wiederkehrender Aufgabenstellungen verwenden möchte, um meinen Code sauber zu organisieren.

Ok wir kommen uns näher.

Du musst nur unterscheiden, wer der Master und wer der Slave ist.
In einem traditionell gepflegten php Umfeld ist jede HTML Seite ein php Hauptscript. Alles andere ist shared. Ich bin mit dieser Architektur sehr ungemütlich.

Etwas anderes ist es, wenn du mehr von einer zentralisierten Behandlung ausgehst. Hier hast du einen Master und viele Slaves. Es kann aber auch sein dass du Clients hast, also solche die auch Slaves von anderen Mastern sind. Jetzt musst du aufpassen, welcher Master diesem Client am meisten seinen Willen aufzudrängen versucht. Ein SMTP Mailversand ist als Client OK, denn der Master ist von der Rückgabe eigentlich weitgehend unabhängig. Aber so etwas wie einen geteilten Formularmanager, der den Bedüfnissen beider Master gerecht werden soll, geht sehr schnell schief.

Perlish gesprochen: Wenn das Masterscript einem Modul einen Parameter Wert zur kontextspezifischen Behandlung übergibt, wobei verlangt wird, dass das Modul in keiner Weise die hergestellte Kanonizität des Feldwertes ändern darf, dann übergibt das Masterscript dem Modul eine Kopie der Variable.
Wenn das Masterscript einem Modul einen Wert übergibt um eine Kanonizität herzustellen, dann übergibt es eine Referenz.

mfg Beat

[Pragma]

Ich gebe auf. Das ist mir unverständliche Theoretisiererei mit gleichzeitig anmaßendem Tonfall. Es ging um eine einfache, sprachunabhängige, Frage.

[Ben]

Hi Struppi

Habe mal angefangen Beat seinen Rat zu folgen, und mich werde mich so langsam von  den 80 ern codes zu trennen.

Nun habe ich nur den Anfan nicht hinbekommen, da ist irgend etwas falsch:

#!/usr/bin/perl -w
use CGI;
$cgi = new CGI;
$cgi->param('tiere');

print "Content-Type: text/html\n\n";

print "<a href=$NV{'SCRIP_NAM'}?tier=Hund>Zum Tier</A> $param{'tiere'}";

Vielen dank Ben

[Struppi]

Nun habe ich nur den Anfan nicht hinbekommen, da ist irgend etwas falsch:

Du hast die Doku mittlerweile gelesen?

#!/usr/bin/perl -w
use CGI;

use strict;

$cgi = new CGI;
$cgi->param('tiere');

Dieser Befehl macht nichts. Du willst:

my @tiere = $cgi->param('tiere');

print "Content-Type: text/html\n\n";

Die CGI Bibliothek hat auch hierfür eine Funktion. Das Skript könnte so aussehen:

#!/usr/bin/perl -w  
use CGI;  
use strict;  
  
my $cgi = new CGI;  
my @tiere = $cgi->param('tiere');  
  
print $cgi->header(), $cgi->start_html(),  
$cgi->a({-href => '?tier=Hund'}, 'Zum Tier'),  
"@tiere",  
$cgi->end_html();  

Struppi.

[Ben]

Hi Ben

Mit diesem Mix zwischen neu und alt kann ich gut aufrüsten/ mich langsam orientieren.

#!/usr/bin/perl -w
use CGI;
use strict;

my $cgi = new CGI;
my @tiere = $cgi->param('tiere');

print "Content-Type: text/html\n\n";
print " <a href=$ENV{'SCRIPT_NAME'}?tiere=Maus>Tiere</A> ";
print "@tiere";

Nun benötige ich eine Gesamtlösung für:

<a href=$ENV{'SCRIPT_NAME'}?tiere=Maus>Tiere</A>
<a href=$ENV{'SCRIPT_NAME'}?dinge=Steine>Steine</A>

und möchte nicht Jeweils verwenden
my @tiere = $cgi->param('tiere');
my @dinge = $cgi->param('dinge');

sondern Z.B:  Hallo $in{'tier'} Hallo $in{'dinge'}
Also so dass egal welcher name= ausgefüllt wird mit $in{' ausgegeben wird

Vielen Dank
Ben

[Ben]

Hallo

Ich meinte natürlich: Hi Struppi
Hatte versehendlich den falsche Abschnitt kupiert sorry!

Ben

[Struppi]

Hi Ben

Mit diesem Mix zwischen neu und alt kann ich gut aufrüsten/ mich langsam orientieren.

#!/usr/bin/perl -w
use CGI;
use strict;

my $cgi = new CGI;
my @tiere = $cgi->param('tiere');

print "Content-Type: text/html\n\n";
print " <a href=$ENV{'SCRIPT_NAME'}?tiere=Maus>Tiere</A> ";
print "@tiere";

Nun benötige ich eine Gesamtlösung für:

<a href=$ENV{'SCRIPT_NAME'}?tiere=Maus>Tiere</A>
<a href=$ENV{'SCRIPT_NAME'}?dinge=Steine>Steine</A>

und möchte nicht Jeweils verwenden
my @tiere = $cgi->param('tiere');
my @dinge = $cgi->param('dinge');

Du brauchsdt die Array schreibweise nur, wenn du erwartest, dass ein Parameter mehrmals vorkommen kann, wie in deiner Ausgangsfrage mit den Checkboxen. So wie es jetzt ist brauchst du kein Array.

sondern Z.B:  Hallo $in{'tier'} Hallo $in{'dinge'}
Also so dass egal welcher name= ausgefüllt wird mit $in{' ausgegeben wird

Kommt drauf an.
Wenn der Parameter nur einmal ankommen kann:

for(qw(tier dinge/) {  
$in{$_} = $cgi->param($_);  
}  

Ist halt nur die Frage, warum diese umkopiererei? Du hast damit die Daten doppelt im Speicher. Einmal im CGI Modul (das die Daten automatisch am Anfang parst - also das was deine readParse Funktion machte).

Struppi.

[Ben]

Hi Struppi

Funktioniert leider nicht

Vieleicht habe mich mich auch falsch ausgedrückt.

Wenn name=hund oder name=katze ausgefüllt wird soll in

Hallo $in{'hund'} oder in Z.B $in{'katze'} der Wert stehen.

So brauche ich wenn ich Z.B ein Formular erstelle

<inpute type =hidden name=tier value=Hund
 <inpute type =hidden name=rasse value=Dobermann

Nur zu schreiben Halllo $in{'tier'} du Bist die rasse $in{'rasse'}

Vielen Dank
Ben

[ben]

Hi Struppi
Also so in etwa müsste es aussehen

$in{$_} = $cgi->param(in);

<inpute type =hidden name=tier value=Hund
<inpute type =hidden name=rasse value=Dobermann

Nur brauche zu schreiben Halllo $in{'tier'} du Bist die rasse $in{'rasse'}

Und kann egal welche werte vorkommen mit dem $in{' beginnen

vielen dank
Ben

[Struppi]

Also so in etwa müsste es aussehen

$in{$_} = $cgi->param(in);

Du hast die Schleife unterschlagen.

<inpute type =hidden name=tier value=Hund
<inpute type =hidden name=rasse value=Dobermann

Wenn du es so in deinem Quellcode hast, kommen beide Werte an.

Struppi.

[Ben]

Hi Struppi

Funkioniert leider nicht

#!/usr/bin/perl -w
use CGI;
#use strict;

my $cgi = new CGI;

$in{$_} = $cgi->param($_);

print "Content-Type: text/html\n\n";
print "<form action= "" method=post>Hallo $in{'tiere'}
<input type="checkbox" name="tiere" value="Hund">Hund<BR>
<input type="checkbox" name="tiere" value="Katze">Katze<BR>
<input type="checkbox" name="tiere" value="Maus">Maus<BR>
<input type=submit></form>";

#_______ Script ENDE _____________

Und

foreach( sort $cgi->param ){
  print $_ ," = ", join( ", ", $cgi->param{$_} ), "\n";
}
Von Beat gibt wohl alles was ausgefüllt wurde aus.

Aber ich möchte $in{' nicht nur im Formular Abschnitt sondern über all verwenden.

Vielen Dank
Ben

[Struppi]

Funkioniert leider nicht

Du hast ja wieder die hälfte weggelassen.

#!/usr/bin/perl -w
use CGI;
#use strict;

strict ist sinnvoll, du musst dann natürlich alle Variabeln deklarieren.

my %in;

my $cgi = new CGI;

$in{$_} = $cgi->param($_);

Hier fehlt immer noch die Schleife. Mir fehlt immer noch die Antwort, welchen Sinn es macht, die Werte alle umzukopieren? Warum willst du unbedingt diesen Hash?

Struppi.

[Ben]

Hallo Struppi

Also das ist so:

Es geht um ein ein Größeres Perl Skript.
Den Abschnit mit dem emailformular ist nur eine Nachbildung um das nun behobene Problem mit dem my @tiere = $cgi->param('tiere'); print MAIL "@tiere"; zu demonstrieren.

Nun basiert aber das komplette Script auf $in{'

Nun müsste ich alle Variablen

$name = $cgi->param('name');
$in{'name'} =$name;

$vorname = $cgi->param('vorname');
$in{'vorname'} =$vorname;

alle kontrollfelder und alle weiteren Befehle wie oben umprogrammiern.
Der read parse von de 80 ern funktioniert  nicht mit  $cgi->param

Am einfachsten wäre

Das alles was mit post oder get aufgerufen wird mit $in{' den Befehl funktioniert.

hat Irgendwas mit parsen string value= zu tun

Vieleicht kannst Du mir helfen
Ben

[Beat]

Nun müsste ich alle Variablen

$name = $cgi->param('name');
$in{'name'} =$name;

$vorname = $cgi->param('vorname');
$in{'vorname'} =$vorname;

alle kontrollfelder und alle weiteren Befehle wie oben umprogrammiern.
Der read parse von de 80 ern funktioniert  nicht mit  $cgi->param

foreach( $cgi->param ){
  push @{ $in{$_} }, $cgi->param($_);
}

oder besser, bei bereits vordefinierten keys in %in

foreach( keys %in ){
  if( $cgi->param($_) ){
    push @{ $in{$_} }, $cgi->param($_);
  }
}

Diese Kopiererei halte ich für sinnleer, es sei denn, es ist damit auch eine Validierung verbunden, wie ich sie in einem früheren Post beschrieben habe.

mfg Beat

[Beat]

Nun müsste ich alle Variablen

$name = $cgi->param('name');
$in{'name'} =$name;

Hallo Beat

Genau das meine ich.
Aber leider funktioniert es nicht.

#!/usr/bin/perl -w
use CGI;
$cgi = new CGI;

foreach( keys %in ){
  if( $cgi->param($_) ){
    push @{ $in{$_} }, $cgi->param($_);
  }
}
print "Content-Type: text/html\n\n";
print "Mein: $in{'beispiel'} <a href=${'SCRIPT_NAME'}?beipiel=1.Beispiel>Test</A>";

Vieleicht findest Du den fehler
Ben

[Ben]

Hi Beat

Sorry,
Hab schob wieder versehndlich den Falschen Namen
in Feld kopiert.
Ben

[Beat]

#!/usr/bin/perl -w
use CGI;
$cgi = new CGI;

foreach( keys %in ){
  if( $cgi->param($_) ){
    push @{ $in{$_} }, $cgi->param($_);
  }
}
print "Content-Type: text/html\n\n";
print "Mein: $in{'beispiel'} <a href=${'SCRIPT_NAME'}?beipiel=1.Beispiel>Test</A>";

Vieleicht findest Du den fehler

Welches der möglcihen Beispiel Werte möchtest du?
Ein Feld kann viele Werte haben, weil das CGI Modul dir immer einen Array entgegennimmt, auch wenn du dur mit einem Element arbeitest

if( defined $in{beispiel}[0] ){
  print 'Ich habe ein 1. Arrayelement: ',
         '<a href="',
          ${'SCRIPT_NAME'}, "?beispiel=", $in{beispiel}[0], '">', $in{beispiel}[0], '</a>';
}
else{
  print 'Beispiel bevölkern',
         '<a href="',
          ${'SCRIPT_NAME'}, "?beispiel=BeispielA">BeispielA</a>';
}

mfg Beat

[Ben]

Hi Beat

Habe nun alles individuell mit  $name= $cgi->param('name'); usw umgeschrieben.
Endlich funktioniert alles.

print "Content-Type: text/html\n\n";
print <<__FEHLER__;
__FEHLER__;

Habe ich jetzt auch schon mit dem neuerem Code ersetzt.
ich weis zwar nicht was und warum das mit ->header besser sein soll.
Aber Irgend einen Grund wird es schon haben.
So richtig bewusst wird mir so etwas immer erst dann wenn ich wie heute mit älterem Zeug vor den Barrieren stehe!

print $cgi->header(), $cgi->start_html(),
$cgi->a({-href => '?tier=Hund'}, 'Zum Tier'),
"@tiere",
$cgi->end_html();

Vielen Vielen Dank für Deine Hilfe!
Auch an: Struppi & Pragma
Ben ist wieder Froh !

[Beat]

und möchte nicht Jeweils verwenden
my @tiere = $cgi->param('tiere');
my @dinge = $cgi->param('dinge');

sondern Z.B:  Hallo $in{'tier'} Hallo $in{'dinge'}
Also so dass egal welcher name= ausgefüllt wird mit $in{' ausgegeben wird

Wenn du den Input direkt zur Kontrolle ausgeben willst:
(im reinen Text Kontext)

foreach( sort $cgi->param ){
  print $_ ," = ", join( ", ", $cgi->param{$_} ), "\n";
}

mfg Beat