Moderne Altenative zu CGI.pm

[pl]

Lange überlegt. Legacy CGI.pm nutzt u.a. Obverlod, d.h., der Name einer hochgeladenen Datei und das dazugehörige Dateihandle steckt in einundderselben Variablen welche die param()-Methode liefert.

Ich habs ein bischen anders gemacht:

Neu gegenüber CGI.pm

Ist, daß die param()-Methode Instanzen der Klasse xCGI::File liefert, was die weitere Verarbeitung hochgeladener Dateien bestimmt. Beispiel:

# Skalarer Kontext liefert das 1. Dateiobjekt
my $file = $self->param('upspot');

# Getter-Methoden für Attribute
$file->content_type;
$file->content_length;

# Original Filename
$file->filename;

# Dateiinhalt, Overload
my $content = $file;

Meine ersten Überlegungen gingen auch dahin, es so zu machen wie PHP, also für hochgeladene Dateien ein dediziertes Array $FILE anzulegen. Da jedoch die Logik nicht das Array befragt sondern den Namen des <input type=file name=upspot>-Feld auf die param() Methode umlegt, macht ein dediziertes Array keinen Sinn und verbleibt somit als Interna. Wenn schon modern dann OOP und wenn schon OOP dann richtig 😉

Trotzdem gewähre ich hier einen Einblick hinter die Kulissen.

MfG

[Christian Kruse]

Hallo pl,

Trotzdem gewähre ich hier einen Einblick hinter die Kulissen.

Du meinst „einen Einblick vor die Kulissen.“

LG,
CK

[pl]

moin,

Trotzdem gewähre ich hier einen Einblick hinter die Kulissen.

Du meinst „einen Einblick vor die Kulissen.“

Die Dumps sind ein Abbild des Codes, sie zeigen wie er funktioniert:

'param' => {
                              'descr' => [
                                           'Meine Dateien'
                                         ],
                              'upspot' => [
                                            bless( {
                                                     'content_length' => 11761,
                                                     'content_type' => 'image/jpeg',
                                                     'filename' => 'ehmetsklinge.jpg',
                                                     'iohandle' => bless( \*Symbol::GEN3, 'IO::String' ),
                                                     'name' => 'upspot'
                                                   }, 'xCGI::File' ),
                                            bless( {
                                                     'content_length' => 17479,
                                                     'content_type' => 'image/jpeg',
                                                     'filename' => 'eichelberg.jpg',
                                                     'iohandle' => bless( \*Symbol::GEN4, 'IO::String' ),
                                                     'name' => 'upspot'
                                                   }, 'xCGI::File' )
                                          ]
                            },

bless{}, xCGI::File zeigt ja, daß die hochgeladenen Dateien zu Instanzen ebendieser Klasse gemacht wurden und das heißt eben auch, daß es es Methoden gibt, welche die Attribute und Dateiinhalt liefern als Getter bzw. Overload. Wobei der Name der Klasse xCGI::File eigentlich uninteressant ist. Die Methoden sind dokumentiert.

MfG

[Christian Kruse]

Hallo pl,

Die Dumps sind ein Abbild des Codes, sie zeigen wie er funktioniert:

Nein. Nur der Code zeigt, wie es funktioniert.

Du musst deinen Code ja nicht veröffentlichen, aber dann erzähle auch nichts von „hinter die Kulissen“ oder es sei „alles öffentlich einsehbar.“ Ist es nicht. Punkt.

LG,
CK

[pl]

hi

Die Dumps sind ein Abbild des Codes, sie zeigen wie er funktioniert:

Nein. Nur der Code zeigt, wie es funktioniert.

Den Code kannst Du Dir auf meiner Site angucken. Es kommt aber darauf an, Datenstrukturen und Schichtenmodelle einer Client/Server~Architektur zu verstehen und zu verstehen wie Klassen zusammenarbeiten. Des Weiteren den Begriff der Transparenz.

Du musst deinen Code ja nicht veröffentlichen, aber dann erzähle auch nichts von „hinter die Kulissen“ oder es sei „alles öffentlich einsehbar.“ Ist es nicht. Punkt.

Doch, ist es und im Übrigen auch sehr umfangreich dokumentiert. Wer sich die Mühe gibt, meine Seiten zu lesen, der findet auch den Code.

Einstieg hier

Punkt.

[Christian Kruse]

Hallo pl,

Die Dumps sind ein Abbild des Codes, sie zeigen wie er funktioniert:

Nein. Nur der Code zeigt, wie es funktioniert.

Den Code kannst Du Dir auf meiner Site angucken.

Link or it didn't happen.

LG,
CK

[Matthias Apsel]

Hallo pl,

Du musst deinen Code ja nicht veröffentlichen, aber dann erzähle auch nichts von „hinter die Kulissen“ oder es sei „alles öffentlich einsehbar.“ Ist es nicht. Punkt.

Doch, ist es und im Übrigen auch sehr umfangreich dokumentiert. Wer sich die Mühe gibt, meine Seiten zu lesen, der findet auch den Code.

Nein. Der findet das, von dem du behauptest, dass es der Code sei. Punkt.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Nein. Der findet das, von dem du behauptest, dass es der Code sei. Punkt.

Gesucht: JS-Magier, der mir eine hier im Forum funktionierende User-Funktion schreibt, die mir aus ". Punkt." ein ". Basta!" macht…

scnr

Gruß
Kalk

[Patrick C.]

Hallo pl,

ich beobachte jetzt schon länger, was du hier so machst.

Meine Einschätzung ist, dass niemand hier ein Problem damit hat, dass du dich mit Dingen wie Serialisierung, CGI.pm-Alternativen und Frameworks beschäftigt. Wenn ich mehr Zeit und Ideen hätte, würde ich auch wieder mehr programmieren und mich mit solchen Dingen beschäftigen.
Aber: Deine Texte helfen nichts, wenn du die zugehörigen Produkte bzw. Quellcodes nicht irgendwo offenlegst. Ich halte auch das, was du da dokumentiert hast, nicht für „umfangreich“. Mir fehlt da zum einen wie schon erwähnt, der Quellcode und zum anderen eben eine Dokumentation der API – dann würde ich es, wenn noch erläuternde Prosatexte dabei sind, als umfangreich bezeichnen.
Und wie Christian schon sagte, wenn der Quellcode wirklich auf deiner Seite ist, dann verlink ihn doch einfach direkt und nicht irgendwelche „Einstiegsseiten“. Beweis uns, zu was deine Programme fähig sind.

Grüße
Patrick

[pl]

hi

ich beobachte jetzt schon länger, was du hier so machst.

Meine Einschätzung ist, dass niemand hier ein Problem damit hat, dass du dich mit Dingen wie Serialisierung, CGI.pm-Alternativen und Frameworks beschäftigt. Wenn ich mehr Zeit und Ideen hätte, würde ich auch wieder mehr programmieren und mich mit solchen Dingen beschäftigen.
Aber: Deine Texte helfen nichts, wenn du die zugehörigen Produkte bzw. Quellcodes nicht irgendwo offenlegst.

Das ist ja nicht wahr. In meinen Artikeln findest Du alles was an Code relevant ist.

Ich halte auch das, was du da dokumentiert hast, nicht für „umfangreich“. Mir fehlt da zum einen wie schon erwähnt, der Quellcode und zum anderen eben eine Dokumentation der API

Studieren heißt: Sich bemühen.

dann verlink ihn doch einfach direkt und nicht irgendwelche „Einstiegsseiten“. Beweis uns, zu was deine Programme fähig sind.

Ich muss hier zwar niemandem was beweisen, aber was mein Code macht beweisen ja die Demos.

Im Übrigen habe ich mehr als 3 Jahre an einem Schichtenmodell gearbeitet, in welchem die Alternative zu legacy CGI.pm nur ein geringer Teil davon ist. Wenn Dir die CODE Beispiele nicht genügen, wirds wohl an Deinem mangelnden Verständnis liegen.

Und wenn Du, wie Du schreibst, schon länger hier beobachtest was ich tu, wird Dir wohl auch nicht entgangen sein, daß Diskussionen über diese Dinge hier im Forum einfach keinen Sinn ergeben.

MfG

[Christian Kruse]

Hallo pl,

In meinen Artikeln findest Du alles was an Code relevant ist.

Nein.

LG,
CK

[Patrick C.]

Hallo pl,

In meinen Artikeln findest Du alles was an Code relevant ist.

Nein. Das sind in erster Linie ein paar API-Aufrufe.

Studieren heißt: Sich bemühen.

Erstens genügt nur bemühen oftmals nicht und zweitens helfen unvollständige Quellen dabei nicht.
Mir bringen deine Codebeispiele nichts, wenn ich nicht weiß, was du intern machst oder zumindest selbst mal mit einem Kompilat Hand anlegen und ausprobieren kann.

Ich muss hier zwar niemandem was beweisen, aber was mein Code macht beweisen ja die Demos.

Sie sagen nur aus, dass sie was machen – was da intern passiert weißt nur du. So ist keinerlei Review möglich, Bugs lassen sich durch einsehbaren Quellcode besser finden.

Im Übrigen habe ich mehr als 3 Jahre an einem Schichtenmodell gearbeitet, in welchem die Alternative zu legacy CGI.pm nur ein geringer Teil davon ist.

Wie gesagt, da hat kein Mensch etwas dagegen, dass du dich mit solchen Dingen beschäftigst.

Wenn Dir die CODE Beispiele nicht genügen, wirds wohl an Deinem mangelnden Verständnis liegen.

Und da haben wir es wieder, du wirst beleidigend.

Und wenn Du, wie Du schreibst, schon länger hier beobachtest was ich tu, wird Dir wohl auch nicht entgangen sein, daß Diskussionen über diese Dinge hier im Forum einfach keinen Sinn ergeben.

Stimmt – und diese Diskussionen könnte man kurzfassen mit „Ein Geisterfahrer? Hundert!“.

Grüße
Patrick

[pl]

Laß Dich einladen:

Du kannst Dich gerne beteiligen an einer von mir angeregten Diskussion über eine zweckmäßige Datenstruktur betreff File Upload.

MfG

[Patrick C.]

Hallo pl,

Laß Dich einladen:

[…]

Und dann? Was habe ich davon? Du stellst deine Ergebnisse doch eh niemandem zur Verfügung.
Und nein, ich sehe für mich nicht unbedingt einen Nutzen dahinter, anhand deiner Ausführungen deine Programme nachzubauen.

Grüße
Patrick

[pl]

moin,

Laß Dich einladen:

[…]

Und dann? Was habe ich davon?

Interessante Frage. Wollen wir die mal rumdrehen: Was habe ich davon, wenn ich mein über Jahrzehnte privat erarbeitetes Knowhow Leuten hinterherwerfe die nicht einen Gedanken dazu eingebracht haben!?

Abgesehen davon, daß ParseMultipart.pm u.a. Perlmodule seit Jahren auf meiner Seite public sind, genauso wie die Konsole sämtliche JS Libraries offenbart die jedermann einsehen kann.

Dann werden Sie doch sicher verstehen Herr Patrick C. daß ich für Leute wie Sie nicht das geringste Verständnis aufbringen kann.

Beim besten Willen nicht!

[Christian Kruse]

Hallo pl,

Interessante Frage. Wollen wir die mal rumdrehen: Was habe ich davon, wenn ich mein über Jahrzehnte privat erarbeitetes Knowhow Leuten hinterherwerfe die nicht einen Gedanken dazu eingebracht haben!?

Zwingt dich ja keiner. Aber dann ist die Behauptung, du gewährtest „einen Blick hinter die Kulissen“ halt eine Lüge.

Ansonsten: wenn du das nicht möchtest, höre bitte auf Werbung für deine Software zu machen (so wie in diesem Thread). Danke.

LG,
CK

[Patrick C.]

Hallo pl,

Interessante Frage. Wollen wir die mal rumdrehen: Was habe ich davon, wenn ich mein über Jahrzehnte privat erarbeitetes Knowhow Leuten hinterherwerfe die nicht einen Gedanken dazu eingebracht haben!?

Wie Christian schon sagte, dann bewirb deine Software nicht in dieser Form und behaupte nicht, du würdest alles wichtige zur Verfügung stellen. Und wenn du die nur Interessierten zur Verfügung stellen willst, dann sag es einfach!

Abgesehen davon, daß ParseMultipart.pm u.a. Perlmodule seit Jahren auf meiner Seite public sind, genauso wie die Konsole sämtliche JS Libraries offenbart die jedermann einsehen kann.

Schön. Und das von dir hier so beworbene CGI-Modul und dein Framework?

Dann werden Sie doch sicher verstehen Herr Patrick C. daß ich für Leute wie Sie nicht das geringste Verständnis aufbringen kann.

Beim besten Willen nicht!

Diese Aussage erschließt sich mir nicht.

Grüße
Patrick

[Regina Schaukrug]

Was habe ich davon, wenn ich mein über Jahrzehnte privat erarbeitetes Knowhow Leuten hinterherwerfe die nicht einen Gedanken dazu eingebracht haben!?

Dein Code hätte, wäre er OpenSource, außer Dir vielleicht abertausende Nutzer und Du könntest mit Implementierungen, Service und Support Geld verdienen. Und vielleicht würde der eine oder andere Fehler finden oder in anderer Weise zur Verbesserung beitragen.

So aber kommt man auf Deine Seite, findet statt des versprochenen Quellcodes ein paar Textschnipsel und ist enttäuscht. Deswegen und weil man es nicht selbst probieren kann hat Dein Framework wohl auch so wenig Nutzer.

[Camping_RIDER]

Aloha ;)

Und wenn Du, wie Du schreibst, schon länger hier beobachtest was ich tu, wird Dir wohl auch nicht entgangen sein, daß Diskussionen über diese Dinge hier im Forum einfach keinen Sinn ergeben.

Na dann lass sie doch, diese Diskussionen. Weder hat dich jemand gezwungen, diesen Thread hier zu starten, noch hatte er irgendeinen Sinn außer deiner selbst-Beweihräucherung.

Ich spreche jetzt nicht als Moderator, sondern als Mensch mit einer subjektiven Meinung: Erspar uns doch einfach deine Postings, solange sie keine ernst gemeinte Frage beinhalten. Deine Mühen, Gründe und Ziele in allen Ehren (es genügt ja, wenn du sie verstehst), aber wir sind nicht dein Klatschvieh und - ich schätze da spreche ich für viele - würden uns freuen, wenn du dein Klatschvieh woanders suchst.

Grüße,

RIDER

[pl]

Artikel ergänzt um Beispielcode zum Hochladen mehrerer Dateien. Zum Vergleich also im Beispiel einmal CODE zu legacy CGI.pm und CODE zur meiner Neuentwicklung xCGI.pm.

Bis auf eine unterschiedliche Handhabe zu Dateiname/Dateihandle, was ganze 2 Zeilen betrifft, ist alles abwärtskompatibel.

MfG

[plp]

Hallo pl,

lange überlegt. Durch dich inspiriert habe ich mir vorgenommen eine moderne Alternative zu index.php zu programmieren. Das von mir entwickelte Framework kann alles was andere Frameworks können. Nur besser und noch viel mehr zusätzlich. Das Framework inklusive CODE ist bestens dokumentiert. Hier ist ein guter Einstiegspunkt. Ein Einblick hinter die Kulissen:

<?php

require 'App.php';

$app = new App();

Wenn schon modern dann OOP und wenn schon OOP dann richtig 😉

Eben 😉

MfG

[pl]

Moin,

lange überlegt.

Natürlich. Das haben andere auch. Respekt! Es gibt sogar welche die denken über Altenativen zu CGI.pm nach (was nicht mehr im Core vertreiben wird) und schreiben sogar darüber. Nur ist da halt keiner dabei, der zu einem praktikablen Ergebnis gekommen wäre!

Wenn schon modern dann OOP und wenn schon OOP dann richtig 😉

Richtig! Sollte vielleicht mal bei PHP so sein, isses aber nicht. Das Wesentliche an OOP ist nämlich, CODE erweiterbar zu machen, also einen CODE zu providen der mit Veränderungen am besten zurechtkommt. Und das ist genau das was PHP nicht kann, was sich u.a. darin äußert, daß bei jedem Release Funktionen als deprecatetd rausfliegen. Sowas hats in Perl noch nie gegeben!

MfG

[Regina Schaukrug]

Und das ist genau das was PHP nicht kann, was sich u.a. darin äußert, daß bei jedem Release Funktionen als deprecatetd rausfliegen. Sowas hats in Perl noch nie gegeben!

Stimmt: Die fürchterlichen Scripte aus Matts Archiv können bis heute genutzt werden...

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

[pl]

Und das ist genau das was PHP nicht kann, was sich u.a. darin äußert, daß bei jedem Release Funktionen als deprecatetd rausfliegen. Sowas hats in Perl noch nie gegeben!

Stimmt: Die fürchterlichen Scripte aus Matts Archiv können bis heute genutzt werden...

Was möchtest Du tun? Über Spaghetticode diskutieren!?

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

Welche denn?

MfG

[Regina Schaukrug]

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

Welche denn?

Beginnen wir "ganz BASIC" mit

• open()

Das verführt zu etwas wie open($FH, ">$file");

Nur ist eben in Linux jedes Zeichen außer NUL, also auch das '>'-Zeichen in Dateinamen erlaubt. Mit der Folge, dass mit $file = '>inputdatei' etwas wie open($FH, ">>inputdatei"); herauskommt.

Example:

#!/usr/bin/perl -w

$s='Hallo Welt';
$file='>test.txt'; # in der Realität z.B. aus dem Dateisystem ausgewählt, Benutzereingabe, weiß der Schwarze woher 
open ($FH, ">$file");
print $FH $s;
close $FH;

~> ./test.pl
~> cat test.txt
Hallo Welt!
~> ./test.pl
~> cat test.pl
Hallo Welt!Hallo Welt!

Eigentlich sollte der Dateiinhalt in der Datei '>test.txt' ersetzt und nicht angehangen werden... Es gibt aber nicht mal eine Warnung. Lösung wäre open() durch eine Funktion zu ersetzen, welche den Modus explizit als Parameter verlangt und nicht derart 'slappy' als Teil des Dateinamens zulässt.

[pl]

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

Welche denn?

Beginnen wir "ganz BASIC" mit

• open()

Das verführt zu etwas wie open($FH, ">$file");

Nur ist eben in Linux jedes Zeichen außer NUL, also auch das '>'-Zeichen in Dateinamen erlaubt. Mit der Folge, dass mit $file = '>inputdatei' etwas wie open($FH, ">>inputdatei"); herauskommt.

Meine Antwort: IO::File OOP:

use IO::File;

my $file = "moin";

my $fh = IO::File->new();
$fh->open($file, O_RDWR|O_CREAT|O_TRUNC) or die $!;
$fh->print("Moin");
$fh->close;

und das seit v5.6 (Jahr 2000). Also wer IO::File und die damit importierten Konstanten nicht nutzt, der hat seit 18 Jahren die Zeit verpennt.

perldoc IO::File

MfG

[Regina Schaukrug]

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

Welche denn?

Beginnen wir "ganz BASIC" mit

• open()

Das verführt zu etwas wie open($FH, ">$file");

Nur ist eben in Linux jedes Zeichen außer NUL, also auch das '>'-Zeichen in Dateinamen erlaubt. Mit der Folge, dass mit $file = '>inputdatei' etwas wie open($FH, ">>inputdatei"); herauskommt.

Meine Antwort: IO::File OOP:

Thema verfehlt. Denn das hat nichts mit meiner Aussage zu tun, dass, wenn aus Perl ein paar Funktionen rausgeflogen wären, das obige nicht mehr möglich wäre. Denn es geht bis heute. Also bin nicht ich derjenige, der "seit 18 Jahren die Zeit verpennt" hat. Die Macher von Perl hätten das insoweit unsichere open() ersetzen, als deprecaded markieren und entfernen müssen.

[Christian Kruse]

Hallo Regina,

Thema verfehlt. Denn sas hat nichts damit zu tun, dass, wenn aus Perl ein paar Funktionen rausgeflogen wären, das obige nicht mehr möglich wäre. Denn es geht bis heute. Also bin nicht ich derjenige, der "seit 18 Jahren die Zeit verpennt" hat. Die Macher von Perl hätten das insoweit unsichere open() ersetzen, als deprecaded markieren und entfernen müssen.

Naja. Ich weiß ja nicht. Man muss Dateinamen aus Drittquellen eh escapen, und das nicht nur bei Perl, allein schon um so Nickeligkeiten wie ../ zu maskieren. Und wenn man das in Perl mit der richtigen Funktion macht (nämlich mit quotemeta), dann ist > auch maskiert.

Und wenn der Dateiname nicht aus einer Drittquelle kommt, dann ist es auch kein Sicherheitsproblem…

LG,
CK

[Regina Schaukrug]

Und wenn man das in Perl mit der richtigen Funktion macht (nämlich mit quotemeta), dann ist > auch maskiert.

Naja.

$file = '>test.txt';
open ( $FH, ">" . quotemeta( $file ) );

Jetzt hab ich eine Datei mit dem Name \>test\.txt. Ich fürchte fast, das war nicht das Ziel. Denn die Datei sollte ja >test.txt heißen.

Es hat schon seine Richtigkeit Modus und Dateiname beim Aufruf strikt zu trennen. open() kann das ja auch, denn mit

$file = '>test.txt';
open ( $FH, '>' , $file );

funktioniert es prächtig. Nur ist eben die dokumentierte Methode mit der Vereinigung von Modus und Dateiname zu einem String in manchen Fällen völlig unhändelbar und sollte weg, weil es eben keine Kunst ist.

[Christian Kruse]

Hallo Regina,

Jetzt hab ich eine Datei mit dem Name \>test\.txt. Ich fürchte fast, das war nicht das Ziel. Denn die Datei sollte ja >test.txt heißen.

Hehe. Prima in den Fuß geschossen.

Es hat schon seine Richtigkeit Modus und Dateiname beim Aufruf strikt zu trennen.

Natürlich. Eine solche Vermischung ist bäh und ist auf die Anlehnung an die Shells zurückzuführen. Derartige APIs haben in Programmiersprachen nichts zu suchen.

Ich wollte auch eher darauf hinaus, dass ich da keine Sicherheitsbedenken habe, denn eine Kontext-Behandlung brauchst du so oder so.

LG,
CK

[Regina Schaukrug]

Natürlich. Eine solche Vermischung ist bäh und ist auf die Anlehnung an die Shells zurückzuführen. Derartige APIs haben in Programmiersprachen nichts zu suchen.

So. Ich bin lbaden. Rückwegs neue Maus kaufen, der Nager macht Doppelklicks wenn's nur einer sein soll.

Der neulich gekaufte Scanner hat gestern vor Freunde gejodelt.

[Camping_RIDER]

Aloha ;)

Der neulich gekaufte Scanner hat gestern vor Freunde gejodelt.

Igitt, wenn der das Jodeln anfängt ist das vielleicht doch kein Modell für mich.

Aber Scherz beiseite, Glückwunsch zum Etappensieg.

Grüße,

RIDER

[Regina Schaukrug]

Aber Scherz beiseite, Glückwunsch zum Etappensieg.

Jetzt wissen auch die letzten drei Richter des LG, warum alle anderen so sauer auf mich sind (Der Typ gewinnt dauernd vor dem OLG). Wahrscheinlich fängt das LG damit an, künftig Richter anderer Gerichte "einzufliegen" sobald mein Name auftaucht.

[Camping_RIDER]

Aloha ;)

Jetzt wissen auch die letzten drei Richter des LG, warum alle anderen so sauer auf mich sind (Der Typ gewinnt dauernd vor dem OLG). Wahrscheinlich fängt das LG damit an, künftig Richter anderer Gerichte "einzufliegen" sobald mein Name auftaucht.

Das war tatsächlich die Frage, die ich mir gestern nach Lektüre deines Beschlusses gestellt habe: Was tut eigentlich ein Landgericht, wenn es keine nicht-befangenen Richter mehr hat und folglich keinen Richter mehr, der ein bestimmtes Verfahren führen kann?

Grüße,

RIDER

[Regina Schaukrug]

Die Befangenheit selbst wird übrigens gar nicht festgestellt. Es wird fest gestellt, dass der Antragsteller Grund dazu hat, wegen einer möglichen Befangenheit des Richters oder der Richter besorgt zu sein. Das senkt einerseits (rein formal) die Schwelle ab der ein Richter abgelehnt werden kann. Andererseits verhindert es eine Vorentscheidung bezüglich einer möglichen Rechtsbeugung und einer ganzen Latte prozessualer Nebenfolgen.

Oh Mann, eh! Jetzt mach ich schon in Rechtstheorie. Wer hätte je gedacht, dass der Streit mit Gravenreuth so ausartet?

[Camping_RIDER]

Aloha ;)

Die Befangenheit selbst wird übrigens gar nicht festgestellt. Es wird fest gestellt, dass der Antragsteller Grund dazu hat, wegen einer möglichen Befangenheit des Richters oder der Richter besorgt zu sein. Das senkt einerseits (rein formal) die Schwelle ab der ein Richter abgelehnt werden kann. Andererseits verhindert es eine Vorentscheidung bezüglich einer möglichen Rechtsbeugung und einer ganzen Latte prozessualer Nebenfolgen.

Richtig! Danke für die Korrektur 😉

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Oh Mann, eh! Jetzt mach ich schon in Rechtstheorie. Wer hätte je gedacht, dass der Streit mit Gravenreuth so ausartet?

Irgendjemand fragte mich in letzter Zeit mal, ob ich denn sicher sei, das richtige Staatsexamen gemacht zu haben.

@Edit: Der @Matthias Apsel wars.

Grüße,

RIDER

[Regina Schaukrug]

Hättest Du statt "schwierig" "heikel" geschrieben, dann hätte man Dich womöglich zwangsweise zum Jurist gemacht.

Die brauchen nämlich dringend fähigen Nachwuchs.

[Camping_RIDER]

Aloha ;)

Die brauchen nämlich dringend fähigen Nachwuchs.

Vor allem in Kassel und Hamburg, nach allem was man so hört 😂

Grüße,

RIDER

[Regina Schaukrug]

Vor allem in Kassel und Hamburg, nach allem was man so hört 😂

Das Problem ist viel größer. Ich könnte aus dem Stegreif noch Düsseldorf und Mönchengladbach nennen. In Mönchengladbach ging nämlich ein beliebter Richter W. ganz plötzlich und unerwartet vor dem Zwangstermin in Rente.

Zuvor hatte er - auch mit Brille - erhebliche Probleme mit dem verstehenden Lesen ganzer Sätze.

Und das war zwar ein Satz von mir - aber eigentlich ein eher kurzer.

[pl]

Wären aus Perl ein paar Funktionen rausgeflogen, dann wäre DAS vielleicht nicht möglich.

Welche denn?

Beginnen wir "ganz BASIC" mit

• open()

Das verführt zu etwas wie open($FH, ">$file");

Nur ist eben in Linux jedes Zeichen außer NUL, also auch das '>'-Zeichen in Dateinamen erlaubt. Mit der Folge, dass mit $file = '>inputdatei' etwas wie open($FH, ">>inputdatei"); herauskommt.

Meine Antwort: IO::File OOP:

Thema verfehlt. Denn das hat nichts mit meiner Aussage zu tun, dass, wenn aus Perl ein paar Funktionen rausgeflogen wären, das obige nicht mehr möglich wäre. Denn es geht bis heute. Also bin nicht ich derjenige, der "seit 18 Jahren die Zeit verpennt" hat. Die Macher von Perl hätten das insoweit unsichere open() ersetzen, als deprecaded markieren und entfernen müssen.

Das von dir geschilderte Problem hat mit der open() Funktion nichts zu tun, sondern mit dem Kontext welcher abhängig von der Plattform ggf. zu beachten ist. Was ich Dir gezeigt habe ist jedoch ein Code der Plattformunabhängig ist. Im Übrigen implementiert Perl's sysopen() die legacy c Funktion mit denselben Konstanten unabhängig von IO::File, war also schon imme eine Alternative.

MfG

[Regina Schaukrug]

Das von dir geschilderte Problem hat mit der open() Funktion nichts zu tun,

Doch. Und da bleibe ich ganz standhaft.

[pl]

Das von dir geschilderte Problem hat mit der open() Funktion nichts zu tun,

Doch. Und da bleibe ich ganz standhaft.

Bugreport an Perl und hier berichten!

MfG

[pl]

Das von dir geschilderte Problem hat mit der open() Funktion nichts zu tun,

Doch. Und da bleibe ich ganz standhaft.

Was eine Bugmeldung wert ist, ist daß FormData die Dateigröße nicht übermittelt. Ich halte das für einen ziemlich schwerwiegenden Designfehler, der das Parsen nicht gerade einfach macht.

MfG

[dedlfix]

Tach!

Was eine Bugmeldung wert ist, ist daß FormData die Dateigröße nicht übermittelt. Ich halte das für einen ziemlich schwerwiegenden Designfehler, der das Parsen nicht gerade einfach macht.

Wie bitte? FormData übermittelt gar nichts. Das ist lediglich ein Container für Key-Value-Paare für Formulardaten. Wenn da eine Datei dabei ist, dann ist das lediglich einer der Values. Mehr hat FormData damit nicht zu tun. Der Wert eines type=file-Feldes, ist dann ein File-Objekt. Wenn da also eine Größenangabe fehlt, dann ist die bei dir nicht in diesem File-Objekt (Eigenschaft size), was seltsam wäre, oder sie ist dir beim Serialisieren für den Transport verlorengegangen, was auch immer du da gemacht hast.

dedlfix.

[Rolf B]

Hallo plp,

Natürlich unterschlägst du das wichtigste. Ohne ein

$app->configure(...); 
$app->run();

kann das doch gar nichts werden!!1!elf!

😉 Rolf

[pl]

Update: Schichtenmodell erklärt. Ist sonst nirgenwo zu finden!

Weiterhin viel Freude damit.

[Felix Riesterer]

Lieber pl,

gewähre ich hier einen Einblick hinter die Kulissen.

wo genau ist der (vollständige!!) Quelltext, den man benötigt, um my $file = $self->param('upspot'); ausführen zu können?

Liebe Grüße,

Felix Riesterer.

[pl]

Hi Felix,

gewähre ich hier einen Einblick hinter die Kulissen.

wo genau ist der (vollständige!!) Quelltext, den man benötigt, um my $file = $self->param('upspot'); ausführen zu können?

Bevor ich Dir den genauen Link dazu hier poste: Wofür brauchst Du das?

MfG

[Patrick C.]

Hallo pl,

wo genau ist der (vollständige!!) Quelltext, den man benötigt, um my $file = $self->param('upspot'); ausführen zu können?

Bevor ich Dir den genauen Link dazu hier poste: Wofür brauchst Du das?

Du hast nichts verstanden.

Grüße
Patrick

[pl]

Du hast nichts verstanden.

Wir beide werden uns nie verstehen! Aber Du bist doch Programierer, was würde denn die Instanz mit einer Datenstruktur (welche die Demo zeigt)

                 'param' => {
                              'descr' => [
                                           'Meine Dateien'
                                         ],
                              'upspot' => [
                                            bless( {
                                                     'content_length' => 17479,
                                                     'content_type' => 'image/jpeg',
                                                     'filename' => 'eichelberg.jpg',
                                                     'iohandle' => bless( \*Symbol::GEN3, 'IO::String' ),
                                                     'name' => 'upspot'
                                                   }, 'xCGI::File' )
                                          ]
                            },

und der Methode my $file = $self->param('upspot') machen um an das Dateiobjekt zu kommen? Richtig: Die Methode param() ist nichts weiter als ein Getter. Das ist trivialer Code.

MfG

[Patrick C.]

Ich wiederhole: Du hast nichts verstanden. Und damit ist die Diskussion für mich beendet.

Grüße
Patrick

[beatovich]

hallo

Bevor ich Dir den genauen Link dazu hier poste: Wofür brauchst Du das?

Weil der Thread Titel ein Modul und nicht eine API zum Thema hat?

[Felix Riesterer]

Lieber pl,

wo genau ist der (vollständige!!) Quelltext, den man benötigt, um my $file = $self->param('upspot'); ausführen zu können?

Bevor ich Dir den genauen Link dazu hier poste: Wofür brauchst Du das?

wenn ich mit Deinem hier geposteten Demo-Code etwas anfangen können soll, benötige ich den dazugehörigen Kontext. Den habe ich nicht. Ich kenne nicht, was in $self enthalten ist und wie es genau funktioniert, da ich seinen Quellcode nicht einsehen kann.

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten und Phantasien und wie toll das alles ist (und um wieviel toller als Etabliertes), aber leider bleibt es bei den Erzählungen, denn Einsicht in Deinen Quelltext (nicht Deinen Beispielcode, sondern Dein <del>ach so tolles</del><ins>nach modernen Methoden entwickeltes</ins> Framework) gewährst Du keinen. Damit verletzt Du ein fundamentales Prinzip von FOSS, nämlich das O, was letzten Endes auch "öffentlich" bedeutet, denn nur wenn der Quellcode öffentlich zugänglich ist, ist er "offen".

Ich schalte mich an dieser Stelle wieder aus der Diskussion aus, denn es führt genau dahin, wohin es bei Dir immer führt: null. Brauchst nicht zu antworten, ich werde es nicht mehr sehen.

Liebe Grüße,

Felix Riesterer.

[pl]

hi,

wo genau ist der (vollständige!!) Quelltext, den man benötigt, um my $file = $self->param('upspot'); ausführen zu können?

Bevor ich Dir den genauen Link dazu hier poste: Wofür brauchst Du das?

wenn ich mit Deinem hier geposteten Demo-Code etwas anfangen können soll, benötige ich den dazugehörigen Kontext. Den habe ich nicht. Ich kenne nicht, was in $self enthalten ist und wie es genau funktioniert, da ich seinen Quellcode nicht einsehen kann.

Von Fachmann zu Fachmann: $self ist dasselbe wie $this. Also stets eine Instanz der aktuellen Package. Und das unabhängig davon, wie mehrere Klassen zusammenwirken, also Inherit, Delegation oder Dependency Injection dahintersteckt. Welche Klassen das sind zeigt der Dump.

Im Übrigen liegen alle meine zum Artikel relevanten Sourcen offen. Wenn da in der Source zu xCGI.pm ein require ParseMultipart steht, muss man sich schonmal selbst die Mühe geben die Suchfunktion zu benutzen denn text/plain kennt keine Links.

MfG

[pl]

PS:

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten

Das machen andere Softwarehersteller auch. Redest Du mit denen auch so wie mit mir!?

MfG

[Christian Kruse]

Hallo pl,

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten

Das machen andere Softwarehersteller auch.

Hier im Forum? Wäre mir noch nicht aufgefallen.

LG,
CK

[pl]

@Felix Riesterer

PS:

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten

Das machen andere Softwarehersteller auch.

Beispiel

Redest Du mit denen auch so wie mit mir!? Und mockierst Dich öffentlich (!), wenn Du auf denen ihren Seiten nicht gleich das findest was Du gerne hättest!?

Das ist ziemlich kulturlos würde ich mal sagen.

Schönen Tag noch.

[Regina Schaukrug]

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten

Das machen andere Softwarehersteller auch.

Beispiel

Najaaaaaaa. Das ist mit dem Beispiel ein ganz klein wenig anders.

• Zum einen sage ich niemanden, dass er die "Mechanik" der Webseite benutzen soll oder kann. Da stellt sich die Frage, ob ich bezüglich der Codeseite überhaupt als "Softwarehersteller" gelten kann. Der Grund ist ganz einfach dass ich niemanden erklären will wie das geht (z.B. ist für die Beschreibungen eine Textdatei mit Markdown zu benutzen, Metadaten wie Version sind als JSON zu formulieren...)
• Zum anderen befriedigt mich die Qualität selbst nicht, weil der verwendete Quelltextbeleuchter ganz fürchterliches HTML-Zeug ausspuckt, welches ich dann wieder mit regulären Ausdrücken repariere.
• Auch die Lib, die aus Markdown HTML macht, ist nicht von mir. Damit sind über 90% oder mehr des Quellcodes von Dritten.
• Der Setup erfolgt nicht mit einem "Schaltpult", sondern mit "Werkzeug" (meinetwegen dem Editor vi) und man muss an mehreren Stellen "schrauben" - sowas will man Dritten nicht zumuten.
• Dann wäre da noch die Suchfunktion, die zwar (wie alle meine Suchfunktionen 😀 ) "ziemlich genial" ist (das gilt auch wenn Wortvorschläge fehlen), aber eine sehr enge Bindung an Linux hat, denn im Kern erledigt grep den Job.
• Zuletzt finden sich wesentliche Teile als benutzbare Bibliotheken genau auf der Seite.

Das wären:

• htmlClasses.js
• Caching für Webprojekte
• FastDeliver
• libGetBreadcrumb
• libError404

[Christian Kruse]

Hallo pl,

Das ist das Problem an Deinen Posts hier: Du erzählst von Deinen Projekten

Das machen andere Softwarehersteller auch.

Beispiel

Redest Du mit denen auch so wie mit mir!? Und mockierst Dich öffentlich (!), wenn Du auf denen ihren Seiten nicht gleich das findest was Du gerne hättest!?

An der von dir verlinkten Stelle wurde keine Werbung betrieben und nicht nach Meinungen gefragt. Großer Unterschied.

LG,
CK

[Camping_RIDER]

Aloha ;)

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Grüße,

RIDER

[pl]

Aloha ;)

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Welche Alternativen zu CGI.pm benutzt Ihr denn?

MfG

[Camping_RIDER]

Aloha ;)

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Keine. Und ich benutze auch kein CGI.pm. Das könnte daran liegen, dass ich noch nie mit Perl gearbeitet habe und das auch keinesfalls vorhabe. Was vermutlich vielen hier so oder so ähnlich gehen wird.

Grüße,

RIDER

[pl]

Aloha ;)

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Keine. Und ich benutze auch kein CGI.pm. Das könnte daran liegen, dass ich noch nie mit Perl gearbeitet habe und das auch keinesfalls vorhabe. Was vermutlich vielen hier so oder so ähnlich gehen wird.

Ok was Perl betrifft. Und was hältst Du von meinem Schichtenmodell? Enctype application/x-www-form-urlencoded und multipart/form-data verkörpern Standards aus Mitte der 90er -- nurmalso nebenbei bemerkt.

MfG

[Camping_RIDER]

Aloha ;)

Ok was Perl betrifft. Und was hältst Du von meinem Schichtenmodell? Enctype application/x-www-form-urlencoded und multipart/form-data verkörpern Standards aus Mitte der 90er -- nurmalso nebenbei bemerkt.

Definiere Schichtenmodell? Da könntest du mich genauso fragen, was ich vom Schrumpfhörnigen Schnarchkackler halte.

Grüße,

RIDER

[pl]

Aloha ;)

Ok was Perl betrifft. Und was hältst Du von meinem Schichtenmodell? Enctype application/x-www-form-urlencoded und multipart/form-data verkörpern Standards aus Mitte der 90er -- nurmalso nebenbei bemerkt.

Definiere Schichtenmodell?

Link siehe oben.

MfG

[Camping_RIDER]

Aloha ;)

Ok was Perl betrifft. Und was hältst Du von meinem Schichtenmodell? Enctype application/x-www-form-urlencoded und multipart/form-data verkörpern Standards aus Mitte der 90er -- nurmalso nebenbei bemerkt.

Definiere Schichtenmodell?

Link siehe oben.

Gut, dann schauen wir doch mal.

Ah. Auf der von dir verlinkten Seite wird genau zwei Mal der Begriff „Schichtenmodell“ erwähnt.

Das Modul xCGI.pm implementiert ein Schichtenmodell und lädt je nach mitgeliefertem Content-Type den entsprechenden Parser. Damit ist die gesamte Übertragungsstecke transparent, d.h., daß bspw. ein Content-Type application/json ohne Weiteres ausgetauscht werden kann gegen den Enctype application/x-www-form-urlencoded ohne daß der CODE zur Datenverarbeitung geändert werden muss: Die Anwendung der param()-Methode ist immer dieselbe.

Okay. Ich weiß nun, was das, was du Schichtenmodell nennst, bewirken soll. Das sagt mir aber noch nicht, was dieses Schichtenmodell ausmacht, nur, was es bewirkt. Wie soll ich das von dir verwendete Schichtenmodell bewerten wenn ich nur rudimentär weiß was es tut?

Schauen wir uns mal die zweite Fundstelle an.

Oh. Das war schon die zweite Fundstelle. Die erste war innerhalb der Überschrift über eben diesem Absatz.

Ich bitte dich darum zu definieren, was für dich "dein Schichtenmodell" ausmachst, und du antwortest mir das stünde ja dort, wo der Link hinführt - und dann hat der Begriff Schichtenmodell dort genau eine Erwähnung?

Come on.

Dir geht es doch gar nicht darum, deine "Frage" beantwortet zu bekommen, sonst würdest du dir mehr Mühe geben, verstanden zu werden...

Wie gesagt. Wir sind nicht dein Klatschvieh.

Grüße,

RIDER

P.S.: Und bevor du auf die Idee kommst: Nein, ich werde mir nicht, um deine Frage zu beantworten, erstmal die Rosinen aus dem Kuchen deiner Website picken. Auch diese Attitüde ist kein Zeichen dafür, dass du aufrichtig gemeinte Fragen stellst.

[pl]

Aloha ;)

Ok was Perl betrifft. Und was hältst Du von meinem Schichtenmodell? Enctype application/x-www-form-urlencoded und multipart/form-data verkörpern Standards aus Mitte der 90er -- nurmalso nebenbei bemerkt.

Definiere Schichtenmodell?

Link siehe oben.

Gut, dann schauen wir doch mal.

Ah. Auf der von dir verlinkten Seite wird genau zwei Mal der Begriff „Schichtenmodell“ erwähnt.

Unter der <h2> Transparenz und Schichtenmodell </h2> (erste Fundstelle) sind die einzelnen Schichten erläutert. Von Schicht 1 bis Schicht 4 jeweils als <h3> ausgezeichnet: Datenerhebung, Serialisierung, Transport und Deserialisierung. Mit dazugehörigen Beschreibungen zum Layer und jeweils ein Name der JS-Datei+Funktionsname bzw. Perl ParseMultipart.

JS Code habe ich auch ins Dokument geholt (weiter oben).

MfG

[Camping_RIDER]

Aloha ;)

Unter der <h2> Transparenz und Schichtenmodell </h2> (erste Fundstelle) sind die einzelnen Schichten erläutert. Von Schicht 1 bis Schicht 4 jeweils als <h3> ausgezeichnet: Datenerhebung, Serialisierung, Transport und Deserialisierung. Mit dazugehörigen Beschreibungen zum Layer und jeweils ein Name der JS-Datei+Funktionsname bzw. Perl ParseMultipart.

Danke für die ausführlichere Erläuterung. Jetzt ist mir zumindest klar, was du mit Schichtenmodell meinst. Deine Erläuterungen dazu sind mir auch soweit schlüssig.

Letztlich stellt sich mir aber die Frage, wozu das alles? Da bin ich noch nicht ganz draus schlau geworden, habe aber eine Vermutung. Liegt der Mehrwert darin, dass du Content aus verschiedenen Quellen nachher in der Deserialisierung (beziehungsweise in dem Stück Software, das danach tätig wird) gleich behandeln kannst, unabhängig vom ursprünglichen Encoding?

Darin sähe ich zwar durchaus einen Mehrwert, verstehe aber trotzdem noch nicht ganz, warum es sinnvoll ist, den Teil, der enctype-spezifisch ist, auf die Zeit vor dem HTTP-Request (und damit doch auf die Clientseite??) auszulagern, anstatt die gesamte Behandlung des Content mit wie-auch-immer-geartetem Content-Type vollständig nach dem Transport zu unternehmen, serverseitig.

Oder liegt da bei mir noch ein weiteres Missverständnis hinsichtlich deines Schichtenmodells vor?

Grüße,

RIDER

[pl]

Moin,

Oder liegt da bei mir noch ein weiteres Missverständnis hinsichtlich deines Schichtenmodells vor?

Ziel und Sinn von Schichtenmodellen ist, neben der Austauschbarkeit der Layer deren Transparenz. D.h., Schichten werden geschaffen um mit den darin angesiedelten Softwarekomponenten ebendiese Schichten unsichtbar zu machen. Transparent heißt ja: Durchsichtig.

In der Anwendung serverseitig: Enctype und Transport spielen keine Rolle mehr. Die Anwendung kennt also weder den Enctype, noch das Transportprotokoll HTTP und auch nicht die HTTP Requestmethode.

Diese Transparenz war schon immer die Philosophie in Lincoln Steins Library CGI.pm. Eine Weiterentwicklung, die seit Jahren überfällig ist, erfordert natürlich eine gewisse Planung und auch dabei ist ein Schichtenmodell äußerst hilfreich. Und selbstverständlich OOP mit ihren mächtigen Möglichkeiten wie Inherit, Overloading, Delegation und Dependency Injection.

Was Clientseitig File.size ist serverseitig $file->content_length und natürlich das Objekt File an sich samt Inhalt.

MfG

[pl]

Transparenz und Mehrwert meines proprietären Enctypes multipart/slice-data offenbaren sich auch hier:

Was Clientseitig File.size ist serverseitig $file->content_length und natürlich das Objekt File an sich samt Inhalt.

Beim Enctype multipart/form-data (FormData Objekt) wird die Größenangabe einer hochzuladenden Datei im Request nicht ermittelt und nicht mitgesendet. Der proprietäre Enctype multipart/slice-data hingegen nutzt die FileAPI moderner Browser und ermittelt die Dateilänge bereits clientseitig.

Transparenz: In $file->content_length ist dieser Unterschied nicht sichtbar.

MfG

[dedlfix]

Tach!

Beim Enctype multipart/form-data (FormData Objekt) wird die Größenangabe einer hochzuladenden Datei im Request nicht ermittelt und nicht mitgesendet. Der proprietäre Enctype multipart/slice-data hingegen nutzt die FileAPI moderner Browser und ermittelt die Dateilänge bereits clientseitig.

Transparenz: In $file->content_length ist dieser Unterschied nicht sichtbar.

Unnötige Programmierung vermeiden: Programmiersprachen bringen Funktionalität zur Größenermittlung von Daten mit (count(), length(), ...). Einfach nutzen, wenn man es braucht.

dedlfix.

[pl]

Tach!

Beim Enctype multipart/form-data (FormData Objekt) wird die Größenangabe einer hochzuladenden Datei im Request nicht ermittelt und nicht mitgesendet. Der proprietäre Enctype multipart/slice-data hingegen nutzt die FileAPI moderner Browser und ermittelt die Dateilänge bereits clientseitig.

Transparenz: In $file->content_length ist dieser Unterschied nicht sichtbar.

Unnötige Programmierung vermeiden: Programmiersprachen bringen Funktionalität zur Größenermittlung von Daten mit (count(), length(), ...). Einfach nutzen, wenn man es braucht.

Ja schon, aber content_length habe ich aus Gründen der Abwärtskompatibilität zu legacy CGI.pm beibehalten.

Und noch ein Mehrwert gegenüber multipart/form-data:

Mein neuer Enctype welcher die FileAPI moderner Browser konsequent nutzt, überträgt nun auch die lokale LastModified in Millisekunden. Attribut $file->mtime, eben erfolgreich getestet 😉

Localtime anschaulich in $file->mtime_local

(was auch die Demo zeigt, Link s.o.)

MfG

[pl]

Tach!

Transparenz: In $file->content_length ist dieser Unterschied nicht sichtbar.

Unnötige Programmierung vermeiden: Programmiersprachen bringen Funktionalität zur Größenermittlung von Daten mit (count(), length(), ...). Einfach nutzen, wenn man es braucht.

Ähm. Ja. Wir befinden uns hier in einer Client+Server Umgebung. Da wäre ersteinmal zu schauen, was der Enctype multipart/form-data überträgt. Nun, die Längenangabe ist nicht dabei, also bleibt nur eine serverseitige Ermittelung derselben. Und das geht erst, nachdem die Binary aus diesem Enctype herausgeschnitten wurde:

content_length => length $bin

Selbstverständlich mit length() wie denn sonst 😉

MfG

[Christian Kruse]

Hallo pl,

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Gar keine. Moderne Frameworks[tm] handhaben das anders, dort kommen die notwendigen Parameter mit in die Funktionssignatur. Im funktionalen Umfeld lässt das so geniale Dinge wie dies hier zu:

defmodule FooWeb.ExampleController do
  def index(conn, %{"search_term" => term}) do
    examples = Foo.Example.search_examples(term)
    render(conn, "index.html", examples: examples)
  end

  def index(conn, _params) do
    results = Foo.Example.list_examples()
    render(conn, "index.html", examples: examples)
  end
end

Das ist ein Beispiel für Phoenix. Zwei unterschiedliche Code-Pfade basierend auf den Parametern, umgesetzt mit pattern matching. ♥️

In Rust mit Rocket würde man das so oder so ähnlich umsetzen:

#[get("/hello?<name>")]
fn hello_named(name: &RawStr) -> String {
    format!("Hello, {}!", name.as_str())
}

#[get("/hello")]
fn hello() -> String {
    format!("Hello, world!")
}

Nicht ganz so schön wie mit Phoenix, aber auch toll ♥️

LG,
CK

[pl]

hi,

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Gar keine. Moderne Frameworks[tm] handhaben das anders, dort kommen die notwendigen Parameter mit in die Funktionssignatur.

Was ist mit Parametern aus STDIN?

MfG

[Christian Kruse]

Hallo pl,

Was ist mit Parametern aus STDIN?

Die gibt es nicht. Das ist kein CGI.

Was du vermutlich meinst: was ist mit Parametern aus POST-Requests?

Bei Phoenix gibt es da keinen Unterschied, das funktioniert genau wie bei GET.

Bei Rocket: im Prinzip genau so:

#[post("/", data = "<input>")]
fn new(input: T) -> String { ... }

Wobei T hier den FormData-Trait implementieren muss. Aber für Strukturen haben sie noch ein paar tolle Sachen eingebaut:

#[derive(FromForm)]
struct Task {
    complete: bool,
    description: String,
}

#[post("/todo", data = "<task>")]
fn new(task: Form<Task>) -> String { ... }

Übrigens funktioniert das sowohl bei Rocket als auch bei Phoenix auch mit JSON im Body.

LG,
CK

[pl]

hi

Was ist mit Parametern aus STDIN?

Die gibt es nicht. Das ist kein CGI.

Was du vermutlich meinst: was ist mit Parametern aus POST-Requests?

Parameter kann es unabhängig von der Requestmethode geben. Sie können an den URL angehängt sein und natürlich auch über Requestheader gesendet werden. Ob Daten aus STDIN zu lesen sind, darüber entscheidet die Angabe im Requestheader Content-Length.

CGI/1.1 beschreibt nur, wie diese Parameter nachgelagerten Prozessen zur Verfügung gestellt werden. Der Common Gateway ist STDIN/STDOUT.

Bei Phoenix gibt es da keinen Unterschied, das funktioniert genau wie bei GET.

Bei Rocket: im Prinzip genau so:

#[post("/", data = "<input>")]
fn new(input: T) -> String { ... }

Wobei T hier den FormData-Trait implementieren muss. Aber für Strukturen haben sie noch ein paar tolle Sachen eingebaut:

#[derive(FromForm)]
struct Task {
    complete: bool,
    description: String,
}

#[post("/todo", data = "<task>")]
fn new(task: Form<Task>) -> String { ... }

Übrigens funktioniert das sowohl bei Rocket als auch bei Phoenix auch mit JSON im Body.

Genau das ist die Transparenz die ich über mein Schichtenmodell erreiche. Damit werden die Enctypes untereinander austauschbar, ohne daß Anwendungscode geändert werden muss. Also ich kann z.B. den Enctype multipart/form-data gegen application/json austauschen oder den Enctype gar nicht definieren, dann gilt der Default.

Meinen Code organisiere ich übrigens auch in Traits, da ist mit Perl5 kein Thema.

MfG

[Christian Kruse]

Hallo pl,

du musst mich nicht belehren. Ich mache das schon seit 1995.

CGI/1.1 beschreibt nur, wie diese Parameter nachgelagerten Prozessen zur Verfügung gestellt werden. Der Common Gateway ist STDIN/STDOUT.

CGI/1.1 beschreibt, dass GET-Parameter in der Umgebungsvariable QUERY_STRING stehen (siehe RFC) und der Request-Body via STDIN hereingepiped wird, siehe RFC.

Umgangssprachlich spricht man von GET- und POST-Parametern.

Genau das ist die Transparenz die ich über mein Schichtenmodell erreiche.

Ja, das ist schön 😀 dagegen sagt ja keiner etwas. Ist allerdings keine weltbewegend neue Erkenntnis. Das machen die Frameworks schon seit Jahren so.

LG,
CK

[pl]

hi,

Ja, das ist schön 😀 dagegen sagt ja keiner etwas. Ist allerdings keine weltbewegend neue Erkenntnis. Das machen die Frameworks schon seit Jahren so.

Kann denn PHP mittlerweile mehr als die beiden Enctype application/x-www-form-urlencoded und multipart/form-data parsen? Also, wenn Daten per POST nicht mit dem Default Enctype sondern als application/json gesendet werden, sind die dann auch in $_POST zu finden?

MfG

[Christian Kruse]

Hallo pl,

Ja, das ist schön 😀 dagegen sagt ja keiner etwas. Ist allerdings keine weltbewegend neue Erkenntnis. Das machen die Frameworks schon seit Jahren so.

Kann denn PHP mittlerweile mehr als die beiden Enctype application/x-www-form-urlencoded und multipart/form-data parsen?

Keine Ahnung. Ich benutze kein PHP und meinte auch nicht PHP, als ich von den Frameworks schrieb.

LG,
CK

[1unitedpower]

Kann denn PHP mittlerweile mehr als die beiden Enctype application/x-www-form-urlencoded und multipart/form-data parsen?

Das kann PHP schon immer™, der rohe HTTP-Request-Body kann in PHP genau wie in Perl über den STDIN-Stream gelesen und anschließend weiterverarbeitet werden. Einen Handle auf den Stream bekommt man in PHP mit fopen('php://input', 'r'), steht auch im Handbuch.

Also, wenn Daten per POST nicht mit dem Default Enctype sondern als application/json gesendet werden, sind die dann auch in $_POST zu finden?

Nein, da nicht. Früher gab es mal eine superglobale Variable $HTTP_RAW_POST_DATA da hätte man die Daten finden können, das Feature wurde aber zu Gunsten der genannten Alternative entfernt.

[pl]

hi,

Also, wenn Daten per POST nicht mit dem Default Enctype sondern als application/json gesendet werden, sind die dann auch in $_POST zu finden?

Nein, da nicht.

Das ist jedoch das was ich meinte und auch das was meine Demo zeigt: Austauschbare und transparente Layer. D.h., daß der Enctype Layer im Anwendungscode gar nicht mehr sichtbar wird, ebnsowenig wie die Datenquelle STDIN und der Transportlayer einschließlich der Requestmethode.

Und diese Transparenz auch in die andere Richtung: Vom Server zum Client. Mit fetch() z.B. kann man eine Response auch als FormData-Objekt wiederherstellen. Demo

MfG

[1unitedpower]

Das ist jedoch das was ich meinte und auch das was meine Demo zeigt: Austauschbare und transparente Layer. D.h., daß der Enctype Layer im Anwendungscode gar nicht mehr sichtbar wird, ebnsowenig wie die Datenquelle STDIN und der Transportlayer einschließlich der Requestmethode.

Okay, dann war die Frage nicht nach PHP, sondern nach PHP-Frameworks, die das angepsrochene Problem angehen. Das lässt sich ebenfalls positiv beantworten, auf Packagist (dem CPAN-Pendant für PHP) finden sich aktuell über 800 Parser für diverse Content-Types. Die lassen sich einfach als Middleware in PHP-Frameworks integrieren, für Middelwars gibt es sogar einen eigenen PSR-Standard, an dem sich viele große PHP-Frameworks und Subcommunities beteiligen, die Dunkelziffer der konformen Frameworks ist vermutlich noch mal sehr viel größer. Nimmt man die zahllosen Parser und Frameworks hinzu, die nicht auf Packagist zu finden sind oder die den Standard nicht implementieren, aber ihre eigene Custom-Lösung anbieten, überwiegt das Angebot doch deutlich die Nachfrage. So leid es mir für dich tut, deine Lösungen sind ihrer Zeit nicht voraus, sondern wiederkäute Kost.

[pl]

Das ist jedoch das was ich meinte und auch das was meine Demo zeigt: Austauschbare und transparente Layer. D.h., daß der Enctype Layer im Anwendungscode gar nicht mehr sichtbar wird, ebnsowenig wie die Datenquelle STDIN und der Transportlayer einschließlich der Requestmethode.

Okay, dann war die Frage nicht nach PHP, sondern nach PHP-Frameworks, die das angepsrochene Problem angehen. Das lässt sich ebenfalls positiv beantworten, auf Packagist (dem CPAN-Pendant für PHP) finden sich aktuell über 800 Parser für diverse Content-Types. Die lassen sich einfach als Middleware in PHP-Frameworks integrieren, für Middelwars gibt es sogar einen eigenen PSR-Standard,

Interessant. Das ist prinzipiell das was ich für Perl entwickelt habe. Nur halt nicht als Standard aber als eine alternative Weiterentwicklung für CGI.pm die seit Jahren fällig ist.

Was Middleware für PHP ist, ist CPAN für Perl.

MfG

[1unitedpower]

Was Middleware für PHP ist, ist CPAN für Perl.

Nein, eine Middelware ist ein Entwurfsmaster zur Trennung unterschiedlicher Verarbeitungsschritte für HTTP-Anfragen. CPAN ist eine Modul-Datenbank für Perl, das sind zwei völlig verschiedene Dinge. Wie ich schon schrieb, das Pendant zu CPAN in PHP ist Packagist.

[pl]

Was Middleware für PHP ist, ist CPAN für Perl.

Nein, eine Middelware ist ein Entwurfsmaster zur Trennung unterschiedlicher Verarbeitungsschritte für HTTP-Anfragen.

Der Begriff war mir schon immer suspekt. Ein Grund mehr, bei meinem Schichtenmodell zu bleiben.

das Pendant zu CPAN in PHP ist Packagist.

Selbstverständlich.

[beatovich]

hallo

Ja, das ist schön 😀 dagegen sagt ja keiner etwas. Ist allerdings keine weltbewegend neue Erkenntnis. Das machen die Frameworks schon seit Jahren so.

Kann denn PHP mittlerweile mehr als die beiden Enctype application/x-www-form-urlencoded und multipart/form-data parsen? Also, wenn Daten per POST nicht mit dem Default Enctype sondern als application/json gesendet werden, sind die dann auch in $_POST zu finden?

Es macht keinen Sinn, den php-core zu bloaten, wenn die gefragte Eigenschaft gerade mal 1-2 zeilen braucht.

[pl]

hallo

Es macht keinen Sinn, den php-core zu bloaten, wenn die gefragte Eigenschaft gerade mal 1-2 zeilen braucht.

Das ist in Perl ganz genauso. Aber mit 1-2 Zeilen ist ein Client/Server~Schichtenmodell nicht implementiert. Das gehört schon ein bischen mehr dazu. Vor allem die Idee, Pioniergeist, Creativität und Beharrlichkeit.

MfG

[pl]

Re:

Hallo pl,

Was ist mit Parametern aus STDIN?

Die gibt es nicht. Das ist kein CGI.

Was du vermutlich meinst: was ist mit Parametern aus POST-Requests?

Bei Phoenix gibt es da keinen Unterschied, das funktioniert genau wie bei GET.

Bei Rocket: im Prinzip genau so:

#[post("/", data = "<input>")]
fn new(input: T) -> String { ... }

Wobei T hier den FormData-Trait implementieren muss. Aber für Strukturen haben sie noch ein paar tolle Sachen eingebaut:

#[derive(FromForm)]
struct Task {
    complete: bool,
    description: String,
}

#[post("/todo", data = "<task>")]
fn new(task: Form<Task>) -> String { ... }

Übrigens funktioniert das sowohl bei Rocket als auch bei Phoenix auch mit JSON im Body.

Dein Code ist übrigens das Gegenteil von Transparenten Layers. Weil 1. der Enctype im Anwendungscode sichtbar wird und 2. die Requestmethode.

MfG

[Matthias Apsel]

Hallo pl,

Dein Code ist übrigens das Gegenteil von Transparenten Layers. Weil 1. der Enctype im Anwendungscode sichtbar wird und 2. die Requestmethode.

Genau. Christian hat 1. keine Ahnung und ihm fehlt 2. die Erfahrung.

Bis demnächst
Matthias

[Christian Kruse]

Hallo pl,

Dein Code ist übrigens das Gegenteil von Transparenten Layers.

Ist das so…

Weil 1. der Enctype im Anwendungscode sichtbar wird

Nein.

und 2. die Requestmethode.

Darüber kann man streiten. Man könnte das so sehen, muss man aber nicht: das sind Annotations, mit denen das Routing implementiert wird.

LG,
CK

[beatovich]

hallo

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Es ist nicht so, dass ich nach einer Alternative suchen muss, auch wenn cgi.pm nicht mehr zu den Core Modulen gehört. Aber es ist Anlass, die leichtgewichtigeren Versionen zu verwenden.

Ein Modul brauche ich nur zur Entgegennahme des Inputs.

[pl]

hallo

Lange überlegt.

Okay, das ist schön. Und wo genau ist nun deine Frage?

Welche Alternativen zu CGI.pm benutzt Ihr denn?

Es ist nicht so, dass ich nach einer Alternative suchen muss, auch wenn cgi.pm nicht mehr zu den Core Modulen gehört. Aber es ist Anlass, die leichtgewichtigeren Versionen zu verwenden.

Genau. Code wird nur nachgeladen wenn er gebraucht wird, eine der altbewährten Stärken von Perl.

MfG