Opened by lichtkind at 2016-05-01 23:24
Natürlich kann PHP nicht auf das zugreifen, was Perl in den Hauptspeicher geladen hat. Bei einem Web-Application-Framework, was sowohl mit Perl als auch mit PHP funktionieren soll, muss daher bereits am Webserver anhand des Request entschieden werden, ob PHP oder Perl für die Response zuständig ist, was ja auch problemlos konfigurierbar ist.
Und wenn die Seiten alle gleich aussehen sollen, muss es einen gemeinsamen Nenner für die Konfiguration geben, sprich: Eine Datei die mit demselben Algorithmus eingelesen wird. D.h., praktisch muss in Perl und in PHP derselbe abstrakte Datentyp verwendet werden.
Es gibt immer genau dann ein Problem, wenn es Abweichungen in der Abstraktion der Datentypen gibt. Problematisch ist z.B. bereits die Serverumgebung, in Perl wie in PHP fast gleich aber es gibt eine Abweichung:
Und jetzt mal was Anderes: An meiner Idee für einem universellen Parser, der um beliebige Content-Types (im Client als Enctype bezeichnet) erweiterbar ist, habe ich lange gearbeitet, nicht zuletzt auch wegen meiner Erkrankung hat das viel Zeit gebraucht. Umsetzen kann das jeder halbwegs begabte Programmierer, genauso wie meine Frameworks: Entscheidend ist nicht das bischen Code sondern immer die Idee.
Es ist unerheblich wie Daten serialisiert werden und dass XML oder JSON plattformunabhängig sind ist deswegen auch eine unsinnige Behauptung, eben weil sich jeder beliebige Serialize-Algorithmus mit jeder beliebigen Programmiersprache auf jeder beliebigen Plattform umsetzen lässt. Entscheidend ist die Einigung auf einen einheitlichen abtrakten Datentyp und so ist es auch mit ein bischen Übung überhaupt kein Problem eine MIME-Mail auf EAV abzubilden weil eine MIME-Mail genauso eine zyklische Datenstruktur abstahiert wie das Muster Entity-Attribute-Value. Dasselbe gilt für multipart/form-data und solche Beispiele lassen sich beliebig fortführen. Bis zu dem Moment, wo ein Entwickler auf die Idee kommt, Literale durch Referenzen ersetzen zu müssen, siehe obenstehend $_SERVER vs. %ENV.
So braucht XML-RPC keineswegs XML um die Daten zu verpacken, aber das nurmal so nebenbei bemerkt. Der Hack bei meinen Frameworks besteht darin, dass Remote-Prozeduren genauso von einer serverseitigen Framework-Instanz ausgeführt werden wie gewöhnliche Requests, was eine nahtlose Integration des Kommandozeilen-Framework in das Web-Application-Framework bedeutet: Es ist derselbe Code und es sind dieselben Libraries und die FW-Instanz hat Vollzugriff auf alle persistenten Daten wie die Konfigurtion und überhaupt den gesamten Content, egal ob im Dateisystem oder in MySQL.
In diesem Zusammenhang einen zweckmäßigen Ersatz für CGI.pm zu finden ist da eher ein gesetzmäßiger Vorgang. Untenstehend meine bisherige Controllstruktur:
Last edited: 2016-05-03 11:57:58 +0200 (CEST)
Und wenn die Seiten alle gleich aussehen sollen, muss es einen gemeinsamen Nenner für die Konfiguration geben, sprich: Eine Datei die mit demselben Algorithmus eingelesen wird. D.h., praktisch muss in Perl und in PHP derselbe abstrakte Datentyp verwendet werden.
Es gibt immer genau dann ein Problem, wenn es Abweichungen in der Abstraktion der Datentypen gibt. Problematisch ist z.B. bereits die Serverumgebung, in Perl wie in PHP fast gleich aber es gibt eine Abweichung:
Code: (dl
)
1
2
3
4
5
6
7
[REQUEST_TIME] => 1462266830
[argv] => Array
(
[0] => C:\Dokumente und Einstellungen\rolf\Desktop\pack.php
)
[argc] => 1
Und jetzt mal was Anderes: An meiner Idee für einem universellen Parser, der um beliebige Content-Types (im Client als Enctype bezeichnet) erweiterbar ist, habe ich lange gearbeitet, nicht zuletzt auch wegen meiner Erkrankung hat das viel Zeit gebraucht. Umsetzen kann das jeder halbwegs begabte Programmierer, genauso wie meine Frameworks: Entscheidend ist nicht das bischen Code sondern immer die Idee.
Es ist unerheblich wie Daten serialisiert werden und dass XML oder JSON plattformunabhängig sind ist deswegen auch eine unsinnige Behauptung, eben weil sich jeder beliebige Serialize-Algorithmus mit jeder beliebigen Programmiersprache auf jeder beliebigen Plattform umsetzen lässt. Entscheidend ist die Einigung auf einen einheitlichen abtrakten Datentyp und so ist es auch mit ein bischen Übung überhaupt kein Problem eine MIME-Mail auf EAV abzubilden weil eine MIME-Mail genauso eine zyklische Datenstruktur abstahiert wie das Muster Entity-Attribute-Value. Dasselbe gilt für multipart/form-data und solche Beispiele lassen sich beliebig fortführen. Bis zu dem Moment, wo ein Entwickler auf die Idee kommt, Literale durch Referenzen ersetzen zu müssen, siehe obenstehend $_SERVER vs. %ENV.
So braucht XML-RPC keineswegs XML um die Daten zu verpacken, aber das nurmal so nebenbei bemerkt. Der Hack bei meinen Frameworks besteht darin, dass Remote-Prozeduren genauso von einer serverseitigen Framework-Instanz ausgeführt werden wie gewöhnliche Requests, was eine nahtlose Integration des Kommandozeilen-Framework in das Web-Application-Framework bedeutet: Es ist derselbe Code und es sind dieselben Libraries und die FW-Instanz hat Vollzugriff auf alle persistenten Daten wie die Konfigurtion und überhaupt den gesamten Content, egal ob im Dateisystem oder in MySQL.
In diesem Zusammenhang einen zweckmäßigen Ersatz für CGI.pm zu finden ist da eher ein gesetzmäßiger Vorgang. Untenstehend meine bisherige Controllstruktur:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
# hier werden die jeweiligen Layer geladen sub _parse_rawdata{ my $self = shift; if( $self->{CONTENT_TYPE} eq 'multipart/c-eav' ){ require cEAV; $self->{eav} = cEAV->decode_eav( $self->rawdata ); $self->{param} = $self->{eav}->{param}; } elsif( $self->{CONTENT_TYPE} eq 'multipart/eav' ){ # coming soon } elsif( $self->{CONTENT_TYPE} eq 'multipart/form-data' ){ require ParseMultipart; $self->{STDIN}->seek(0,0); $self->{param} = ParseMultipart->parse_multipart( $self->{STDIN} ); } elsif( $self->{CONTENT_TYPE} eq 'application/json' ){ require JSON; my $json = JSON->new; $self->{json} = $json->decode($self->rawdata); $self->{param} = $self->{json}{param}; } elsif( $self->{CONTENT_TYPE} eq 'bserialize/av' ){ require bSerialize; my $bs = bSerialize->new; my $binary = $self->rawdata; $self->{param} = $bs->bin2av( \$binary ); } else{ # Default Enctype # Parameter: Name => [Value], application/x-www-form-urlencoded $self->{param} = $self->qparse($self->rawdata); } }
Last edited: 2016-05-03 11:57:58 +0200 (CEST)